perm filename CLCOMP.MSG[COM,LSP]8 blob
sn#871541 filedate 1989-03-24 generic text, type C, neo UTF8
COMMENT ⊗ VALID 00002 PAGES
C REC PAGE DESCRIPTION
C00001 00001
C00002 00002
C00003 ENDMK
C⊗;
∂13-Mar-89 1045 CL-Compiler-mailer Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89 10:44:47 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 555837; Mon 13-Mar-89 13:42:11 EST
Date: Mon, 13 Mar 89 13:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
To: David N Gray <Gray@DSG.csc.ti.com>, Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@sail.stanford.edu, Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>,
KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <2814804793-2851395@Kelvin>
Message-ID: <19890313184158.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 13 Mar 89 12:13:13 CST
From: David N Gray <Gray@DSG.csc.ti.com>
> How about some wording like:
>
> The extent of the environment objects passed to MACROEXPAND or
> MACROEXPAND-1 by COMPILE-FILE, COMPILE, and EVAL is the dynamic extent
> during which the macro and its expansion are processed. In
> particular, the extent includes the expansion of any other macro calls
> appearing lexically within the form returned from MACROEXPAND or
> MACROEXPAND-1.
That would be fine.
It wouldn't be fine with me. I would much prefer that we use the same
definition of dynamic extent here that we use everywhere else, namely
the extent ends when the macroexpander function returns. That way we
don't have to spend the next year figuring out precisely what the
term "processed" means. I have already thought of two problems with it.
> I think this would fit in with issue SYNTACTIC-ENVIRONMENT-ACCESS, but
> I'm still confused about why you would still need COPY-ENVIRONMENT.
COPY-ENVIRONMENT would only be needed if there are implementations using
stack list environments that disappear as soon as the macro expander
returns. Kent, does Symbolics need this?
I don't think Symbolics needs or wants COPY-ENVIRONMENT. However, Symbolics
Genera does use macro expansion environments with dynamic extent. I believe
Symbolics Cloe does also, although I haven't checked.
∂13-Mar-89 1034 Common-Lisp-Object-System-mailer Re: remote environments
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 10:34:52 PST
Received: from Semillon.ms by ArpaGateway.ms ; 13 MAR 89 10:25:22 PST
Date: Mon, 13 Mar 89 10:22 PST
From: Gregor.pa@Xerox.COM
Subject: Re: remote environments
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
Sandra.J.Loosemore%defun@cs.utah.edu, David N Gray <Gray@DSG.csc.ti.com>,
Patrick%defun@cs.utah.edu, Dussud <dussud@lucid.com>, Kim A. Barrett
<IIM%ECLA@ECLC.USC.EDU>, cl-compiler@sail.stanford.edu,
common-lisp-object-system@sail.stanford.edu
Fcc: BD:>Gregor>mail>outgoing-mail-5.text.newest
In-Reply-To: <8903131444.AA02017@defun.utah.edu>
Message-ID: <19890313182248.2.GREGOR@SPIFF.parc.xerox.com>
Line-fold: no
Date: Mon, 13 Mar 89 07:44:15 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
At least three of us (Moon, Gray, and myself) appear to agree that
DEFMETHOD should not make the method function callable at compile time
(by analogy to DEFUN). If you're using the term "initfunctions" to
refer to things like the SHARED-INITIALIZE method, then no, they can't
be called at compile-time by default.
Yes, I understood that. I didn't mean to suggest that it was an open
question, just that it was a basic question. Answering it as we have
has some implications that I don't fully understand yet. More on that
in a second.
Personally, I think we could leave the issue of whether remote classes
exist or are instantiable unspecified for now. It would give those of
you who are trying to sort out the meta-object protocol more freedom,
and I don't think it would place an unreasonable burden on programmers.
This misses the major point from my message (looking back at my message,
the point is obscured). The funny thing about specifying `meta-level'
behavior is that while we can specify minimal behavior, we can't specify
minimally. In short, I think we have to take a stand on whether there
are remote metaobjects or not.
We must decide so that users who define their own metaobject classes can
know under what conditions those classes will be instantiated. If a
user defined metaobject class is instantiated in the remote environment
some things will be `different'. At the very least it will have these
funny remote functions. User code needs to know that it must deal with
this.
I believe it is possible to take a minimal stance on what we specify.
One such workable minimal stance is to say that no portable metaobject
class will ever be instantiated in the remote environment. In this
scheme, the implementation could instantiate its own metaobjects in the
remote environment, and it could instantiate placeholders for user
metaobjects as well. This would make it possible to do the kind of file
compilation we all know and love when doing normal programming. Only
portable `compilers' would have to use the load, then compile approach.
-------
∂13-Mar-89 1043 CL-Compiler-mailer Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 10:43:22 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA24753; Mon, 13 Mar 89 11:41:10 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02266; Mon, 13 Mar 89 11:41:05 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131841.AA02266@defun.utah.edu>
Date: Mon, 13 Mar 89 11:41:04 MST
Subject: Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
To: David N Gray <Gray@DSG.csc.ti.com>
Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore),
cl-compiler@sail.stanford.edu,
"David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
"Kim A. Barrett" <IIM%ECLA@ECLC.USC.EDU>,
KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: David N Gray <Gray@DSG.csc.ti.com>, Mon, 13 Mar 89 12:13:13 CST
Aha, that makes more sense now. However, how would you handle
AUGMENT-ENVIRONMENT without modifying your implementation?
Presumably it would have to add things to the list in the special
variable, but how would you know when to take them off again?
For example, suppose I've written a code-walker using the primitives
in issue SYNTACTIC-ENVIRONMENT-ACCESS, and I'm walking a form like
(let ((x ...))
(let ((y ...))
<body-1>)
(let ((z ...))
<body-2>))
To process <body-1>, I'd want to augment the environment from the outer
LET to contain the binding for Y. But that binding has to be removed
before I add the binding for Z and process <body-2>.
One other thing that has occured to me on this issue is that it is
only information about lexical definitions that needs to be protected
against bashing, and that the implementation could be permitted to
bash global definitions in the environment. This would eliminate the
objection to having to copy all the information about the compiler's
model of the remote environment, plus it's consistent with the
treatment of NIL to mean "whatever's in the local global environment
at the time you want to access that information".
-Sandra
-------
∂13-Mar-89 1054 Common-Lisp-Object-System-mailer Re: remote environments
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Mar 89 10:53:53 PST
Received: by ti.com id AA17001; Mon, 13 Mar 89 12:49:36 CST
Received: from Kelvin by tilde id AA27491; Mon, 13 Mar 89 12:41:40 CST
Message-Id: <2814806442-2950447@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 13 Mar 89 12:40:42 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: Gregor.pa@Xerox.COM
Cc: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
Sandra J Loosemore <sandra%defun@cs.utah.edu>,
Patrick Dussud <dussud@lucid.com>,
"Kim A. Barrett" <IIM%ECLA@ECLC.USC.EDU>,
cl-compiler@sail.stanford.edu,
common-lisp-object-system@sail.stanford.edu
Subject: Re: remote environments
In-Reply-To: Msg of Sun, 12 Mar 89 20:00 PST from Gregor.pa@Xerox.COM
> In this message I question, once again, the existence of remote
> metaobjects. I may be behind the times here, but since no one answered
> the long message I sent about why we could do without remote metaobjects
> I am still stuck at that point.
...
> I don't understand these comments. It seems to me that the only real
> questions are "is there a remote class object?" and "if so, how are
> remote functions represented?".
I don't see that we need to have separate classes for representing
things in the remote environment. The problem with closures is very
easily dealt with by performing compile-time remote-environment
definitions only for top-level forms. So I would say that yes there are
class objects in the remote environment and they look just like any
other class objects. Generic functions and methods are another matter
though; permitting compile-time instantiation of classes in the remote
environment should not be difficult, but it may not be very useful
without having the methods for that class available.
> > This is an interesting idea, but I think it's too restrictive. Here's a
> > plausible and many-times proposed application for metaobjects which
> > would not be possible if we adopted this idea. Suppose you made an
> > optimizing compiler that is allowed to assume that no class
> > redefinitions, no method redefinitions, and no newly-defined subclasses
> > will be created at run time. The compiler is to take advantage of this
>
> I certainly don't want to prevent any implementation from doing that.
> The real issue is what is the minimal functionality that all
> implementations must support.
>
> As Moon says in a later message, the issue here is not what the
> implementation can do, its what portable programs can do. It needs to
> be the case that one can write a portable, metaobject `compiler'. Many
> people have wanted to do this. People currently do this with PCL which
> surely has no remote metaobjects.
It sounds like there are two issues here: (1) what a
standard-conforming Common Lisp compiler is required to do, and (2) what
a portable program is able to do with the meta-object protocol features
provided. I was only addressing (1), but it sounds like you and Moon
have (2) in mind.
∂13-Mar-89 1113 CL-Compiler-mailer issue COMPILER-VERBOSITY, version 6
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89 11:13:45 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 555892; Mon 13-Mar-89 14:11:06 EST
Date: Mon, 13 Mar 89 14:10 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-VERBOSITY, version 6
To: barmar@Think.COM
cc: CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: <19890313165001.9.BARMAR@OCCAM.THINK.COM>
Message-ID: <890313141049.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
[X3J13 removed.]
Date: Mon, 13 Mar 89 11:50 EST
From: Barry Margolin <barmar@Think.COM>
I see the benefit of :PRINT, but do we really need :VERBOSE?
At this stage of the game I don't see the need to add
gratuitous features like this.
The original reason this was generated is that some implementations
already offer this `gratuitous feature' and some users (e.g., me) want a
way to get them to turn it off. Adding a keyword is little extra effort
for those implementations not already providing the option; removing the
functionality is something I thought we'd get opposition to if we didn't
provide a way for people to switch it back on in implementations where
they were used to it.
Note, too, that the return value of compile-file gets lost if you put
calls to FORMAT in, so the rewrite is more complex if you care about
the data flow.
∂13-Mar-89 1149 CL-Compiler-mailer Re: Issue CONSTANT-COMPILABLE-TYPES, version 7
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 11:49:45 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA15985; Mon, 13 Mar 89 11:23:36 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA20038; Mon, 13 Mar 89 11:19:51 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA23772; Mon, 13 Mar 89 11:23:23 PST
Date: Mon, 13 Mar 89 11:23:23 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903131923.AA23772@clam.sun.com>
To: cperdue@Sun.COM, rpg@lucid.com
Subject: Re: Issue CONSTANT-COMPILABLE-TYPES, version 7
Cc: cl-compiler@sail.stanford.edu
> Therefore, variables are mutable, and EQness required by the standard
> for conforming programs should be maintained.
>
Excuse me, but we can't just carry the usual "EQness required by the
standard" over to file compilation, regardless of the details of what
we think that requirement is.
Like READ and PRINT, file compilation gets Lisp's "feet" into the
distributed world in the sense that one cannot define the behavior
of everything with respect to a single Lisp address space.
> If there is a problem, I
> think it is better to change the semantics of Common Lisp rather than
> making compiling and loading special cases.
Well, that would be facing the problem squarely. I'll let you
stick your fist into the tar baby first. :-} .
∂13-Mar-89 1151 Common-Lisp-Object-System-mailer Re: remote environments
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 13 Mar 89 11:51:37 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA26986; Mon, 13 Mar 89 12:43:02 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA02353; Mon, 13 Mar 89 12:42:59 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903131942.AA02353@defun.utah.edu>
Date: Mon, 13 Mar 89 12:42:58 MST
Subject: Re: remote environments
To: Gregor.pa@Xerox.COM
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
David N Gray <Gray@DSG.csc.ti.com>, Patrick Dussud <dussud@lucid.com>,
Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>, cl-compiler@sail.stanford.edu,
common-lisp-object-system@sail.stanford.edu
In-Reply-To: Gregor.pa@Xerox.COM, Mon, 13 Mar 89 10:22 PST
> Date: Mon, 13 Mar 89 10:22 PST
> From: Gregor.pa@Xerox.COM
>
> We must decide so that users who define their own metaobject classes can
> know under what conditions those classes will be instantiated.
Perhaps my ignorance is showing, but I didn't think that chapters 1 &
2 gave users enough information to define their own metaobject classes
anyway. If making this statement is only of interest for users of the
part of CLOS that is specified in chapter 3, I don't think we absolutely
positively need to say anything about this now. Frankly, I question
whether the metaobject protocol is stable enough that we should even
*try* to do so now.
> I believe it is possible to take a minimal stance on what we specify.
> One such workable minimal stance is to say that no portable metaobject
> class will ever be instantiated in the remote environment. In this
> scheme, the implementation could instantiate its own metaobjects in the
> remote environment, and it could instantiate placeholders for user
> metaobjects as well. This would make it possible to do the kind of file
> compilation we all know and love when doing normal programming. Only
> portable `compilers' would have to use the load, then compile approach.
I guess part of the problem I'm having is understanding what this
implies for normal user code. I think we ought to say something in
the standard that your average ignoramus like me can understand, about
how to arrange programs so they will compile correctly. The current
writeup does that, your statement here doesn't.
Is there anything in the MINIMAL proposal that is fundamentally
incompatible with this stance? I can see that wanting classes to be
instantiable at compile-time (as in proposal NOT-SO-MINIMAL) would
imply that the DEFCLASS macro causes some kind of metaobject to be
created at compile time. However, it would still be possible to do
without distinguished "remote" metaobjects by having DEFCLASS make the
class fully defined in the compile-time environment.
-Sandra
-------
∂13-Mar-89 1206 CL-Compiler-mailer Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Mar 89 12:06:40 PST
Received: by ti.com id AA00360; Mon, 13 Mar 89 14:06:16 CST
Received: from Kelvin by tilde id AA29423; Mon, 13 Mar 89 13:51:43 CST
Message-Id: <2814810638-3202528@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 13 Mar 89 13:50:38 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu,
"David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>,
"Kim A. Barrett" <IIM%ECLA@ECLC.USC.EDU>
Subject: Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
In-Reply-To: Msg of Mon, 13 Mar 89 11:41:04 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Aha, that makes more sense now. However, how would you handle
> AUGMENT-ENVIRONMENT without modifying your implementation?
> Presumably it would have to add things to the list in the special
> variable, but how would you know when to take them off again?
I hadn't thought about that before, but that could be handled by using
the interpreter's representation for the AUGMENT-ENVIRONMENT data and
having the environment accessors look there before using the compiler's
special variables. The compiler wouldn't ever be looking at an
augmented environment; macros would, but the interpreter and compiler
already need to use the same representation for local macro definitions.
∂13-Mar-89 1221 CL-Compiler-mailer Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Mar 89 12:21:26 PST
Received: by ti.com id AA00520; Mon, 13 Mar 89 14:20:16 CST
Received: from Kelvin by tilde id AA29821; Mon, 13 Mar 89 14:08:24 CST
Message-Id: <2814811645-3263023@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 13 Mar 89 14:07:25 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
cl-compiler@sail.stanford.edu,
"Kim A. Barrett" <IIM%ECLA@ECLC.USC.EDU>,
KMP@STONY-BROOK.SCRC.Symbolics.COM
Subject: Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
In-Reply-To: Msg of Mon, 13 Mar 89 13:41 EST from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> It wouldn't be fine with me. I would much prefer that we use the same
> definition of dynamic extent here that we use everywhere else, namely
> the extent ends when the macroexpander function returns. That way we
> don't have to spend the next year figuring out precisely what the
> term "processed" means. I have already thought of two problems with it.
But if a strict dynamic extent is adopted, then environments can't be
included in the expansion of the macro, and functions such as
FIND-CLASS, ENSURE-GENERIC-FUNCTION, and ENSURE-CLASS that are supposed
to accept environment arguments will need to be redesigned.
∂13-Mar-89 1233 CL-Compiler-mailer Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89 12:33:05 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 555974; Mon 13-Mar-89 15:29:18 EST
Date: Mon, 13 Mar 89 15:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue MACRO-ENVIRONMENT-EXTENT, version 2
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, cl-compiler@sail.stanford.edu,
Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>, KMP@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <2814811645-3263023@Kelvin>
Message-ID: <19890313202914.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Mon, 13 Mar 89 14:07:25 CST
From: David N Gray <Gray@DSG.csc.ti.com>
> It wouldn't be fine with me. I would much prefer that we use the same
> definition of dynamic extent here that we use everywhere else, namely
> the extent ends when the macroexpander function returns. That way we
> don't have to spend the next year figuring out precisely what the
> term "processed" means. I have already thought of two problems with it.
But if a strict dynamic extent is adopted, then environments can't be
included in the expansion of the macro, and functions such as
FIND-CLASS, ENSURE-GENERIC-FUNCTION, and ENSURE-CLASS that are supposed
to accept environment arguments will need to be redesigned.
That is correct.
∂13-Mar-89 1319 CL-Compiler-mailer Re: issue SAFE-CODE, version 1
Received: from A.ISI.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 13:18:22 PST
Date: 13 Mar 1989 16:14-EST
Sender: ROSENKING@A.ISI.EDU
Subject: Re: issue SAFE-CODE, version 1
From: ROSENKING@A.ISI.EDU
To: cl-compiler@SAIL.STANFORD.EDU
Message-ID: <[A.ISI.EDU]13-Mar-89 16:14:03.ROSENKING>
In-Reply-To: <8903131726.AA02193@defun.utah.edu>
I believe that the basis for this proposal is well justified and I support
the intent of what is being defined. I'm not 100% for the naming though.
Anyhow, I have seen these type of problems come up before in implementations
of C and FORTRAN, where it was unclear what the default values were for
OPTIMIZE and DEBUG are and so I agree that some known universal default
should be specified, though perhaps by a name besides SAFE-CODE.
Jeff Rosenking
∂13-Mar-89 1352 CL-Cleanup-mailer Issue: LOAD-OBJECTS (Version 3)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 13:51:55 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA16534; Mon, 13 Mar 89 11:37:16 PST
Received: from lukasiewicz.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA20771; Mon, 13 Mar 89 11:32:38 PST
Received: by lukasiewicz.sun.com (4.0/SMI-4.0)
id AA00318; Mon, 13 Mar 89 11:35:38 PST
Date: Mon, 13 Mar 89 11:35:38 PST
From: jrose@Sun.COM (John Rose)
Message-Id: <8903131935.AA00318@lukasiewicz.sun.com>
To: sandra%defun@cs.utah.edu
Cc: rpg@lucid.com, CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu,
Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Sat, 11 Mar 89 18:42:56 MST <8903120142.AA00878@defun.utah.edu>
Subject: Issue: LOAD-OBJECTS (Version 3)
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Date: Sat, 11 Mar 89 18:42:56 MST
...
Have two generic functions, not one. The first would get called by
compile-file and it would return a list of components (or whatever)
that are required to reconstruct the object. The compiler would dump
this list of objects in its usual way. The loader would apply the
second generic function to this list to reconstruct the object. It
avoids the nasty syntax you object to, doesn't require functions to be
dumpable, doesn't require any special support for circular constants,
and ought to be real easy to add to the compiler/loader. (You could
essentially convert the constant into a LOAD-TIME-VALUE expression.)
Two objections here:
One is that this scheme cannot support circular constants. Since
LOAD-OBJECTS is not the issue which determines circular constants, it
probably should not force or presuppose a decision against circular
constants.
Supporting circular constants requires two phases of object
construction, one which creates at least a valid reference to the
object, and a second one which further initializes the object (at least
by patching in back-references to finish building circularities).
In order for your technique to support circular constants, you still
need #'make-load-form to return two things, not one. It would return
two argument lists, and there would be two load-time generic functions.
The other objection is that an arglist for a fixed generic function is
less general and more complex than an EVAL-able form (or a thunk, as rpg
suggests). The programmer must coordinate the construction of the
argument list with the definition of the method to digest it at load
time, which is probably on a different page of the source code. What's
the advantage to offset the complexity and lack of flexibility?
Perhaps method combination within the load-time generic gives a clean
way to modularize the construction of an object of multiple classes?
Someone will have to show me an example of this before I believe it.
Until then, I think the simplicity of thunks (either EVAL-able or
FUNCALL-able) is far preferable.
By the way, I also share rpg's preference for functions over forms,
because functions are parametrized naturally via captured lexicals,
whereas you've got to use backquote to parametrize forms, a more
error-prone technique.
Here's an example which suggests the relative conciseness of the techniques:
;; Using functions:
(defmethod make-load-form ((x myclass))
(let ((p <pval>) (q <qval>) (r <rval>))
#'(lambda () <code>)))
;; Using forms:
(defmethod make-load-form ((x myclass))
`(let ((p ',<pval>) (q ',<qval>) (r ',<rval>))
<code>))
;; Using a generic:
(defmethod make-load-form ((x myclass))
`(cookie00012 :p ,<pval> :q ,<qval> :r ,<rval>))
(defmethod load-time-constructor
((lf (eql 'cookie00012)) &key p q r &allow-other-keys)
<code>)
-Sandra
-------
-- John
∂13-Mar-89 1501 CL-Compiler-mailer Issue MACRO-ENVIRONMENT-EXTENT
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:01:20 PST
Date: Sun 12 Mar 89 16:06:56-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue MACRO-ENVIRONMENT-EXTENT
To: cl-compiler@SAIL.STANFORD.EDU
cc: iim%ECLA@ECLC.USC.EDU
Message-ID: <12477531375.30.IIM@ECLA.USC.EDU>
I think the suggestions to move things to Chapter 3 if they are currently
specified as requiring an environment argument are misguided. Chapter 3
probably won't make it into the standard, but we don't want to shut the door
on it for all time because we didn't take into account the needs of Chapter 3
when we "solved" some of these sticky problems.
kab
-------
∂13-Mar-89 1458 CL-Compiler-mailer Issue MACRO-ENVIRONMENT-EXTENT
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 14:58:11 PST
Date: Sat 11 Mar 89 19:36:38-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue MACRO-ENVIRONMENT-EXTENT
To: Moon@SCRC-STONY-BROOK.ARPA
cc: iim%ECLA@ECLC.USC.EDU, cl-compiler@SAIL.STANFORD.EDU
Message-ID: <12477307405.30.IIM@ECLA.USC.EDU>
Your recent statement that you are convinced that CLOS made a mistake with
regard to environments has made me reconsider the problem, and I think I may be
convincable. I'm going to throw some thoughts your way to see if maybe we can
reach some definite, defendable, conclusions on the subject.
Right now, our implementation provides some functions for manipulating remote
environments without specifying the environment as an argument. These
functions work by referencing a special variable bound by the compiler.
Currently the only places it is legit to put calls to them is in the compiler
itself or in (eval-when (compile) ...) forms. It wouldn't be hard to arrange
for a compiler-like user program to be able to use these.
It is because these functions usually seem to be adequate for the job that I
think you might be right. The places where they currently don't work seem to
be precisely those places where somebody has said that a function (like
find-class) takes an environment argument just to distinguish between remote
and local environments.
Suppose we were to say that T is a special indicator for the remote null
lexical environment, just as NIL is a special indicator for the local null
lexical environment. Then find-class could be defined as
(defun find-class (name &optional (errorp t) env)
(cond ((and (environment-remote-p env)
<< look it up in the remote environment, in some special >>))
(<< look it up in the local environment >>)
(errorp (error ...))
(t nil)))
and your suggestion of using T as the argument to find-class works, and all the
places which might want to call find-class can either pass in an environment
argument if they've got one handy (rather than forcing them to call
environment-remote-p and passing the result) and it is legit to do so within
the constraints of the extent of the environment, or they can call
environment-remote-p and pass the result if they can't use the environment
because of the extent problem, or they can use T or NIL if they happen to know
which they want.
Saying that T is a null environment looks a little funny, but I thing something
like this would simplify some of SYNTACTIC-ENVIRONMENT-ACCESS and sort of
normalize everything.
To make this all fly we would have to say some things about when it is legit to
use T as an environment, but I don't think this is hard. Admitedly, people can
get strange bugs if they use it wrongly, but many of the same kinds of problems
can occur with passing around environments that are real data structures.
The one thing I'm concerned about is the use of a special to hold the
environment. I think its ok, as long as there is some specified way to bind it
and everybody who wants to do compile-file-like things uses that mechanism.
Some sort of with- construct, and don't even bother to document what the
special variable is, seems to me to be the right way to go. The only case I
can think of where this might be a problem is if somebody were trying to
distribute the work of their 'compilation' over multiple processes/processors,
and I think any system that would support doing such a thing is likely to have
some mechanism for doing what's needed, like being able to have process trees,
with children inheriting bindings from parents.
Note that this does throw away the possibility of operating on multiple
distinct remote environements at the same time. I mentioned this in a message
a while back to the small group discussing remote environment issues. Is that
so bad? Maybe we'll just have to say "Tough. You can't do it."
Note that I read your message after sending out version 3 of
syntactic-environment-access, which includes some stuff that goes off in a
different direction from what I think you are suggesting. If we can agree to
something like what I'm describing here, that proposal will have to be yanked
around to a somewhat different path.
kab
-------
∂13-Mar-89 1500 CL-Compiler-mailer Issue WITH-COMPILATION-UNIT
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:00:50 PST
Date: Sun 12 Mar 89 16:00:00-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue WITH-COMPILATION-UNIT
To: kmp@SCRC-STONY-BROOK.ARPA
cc: cl-compiler@SAIL.STANFORD.EDU, iim%ECLA@ECLC.USC.EDU
Message-ID: <12477530111.30.IIM@ECLA.USC.EDU>
I strongly oppose the behavior you proposed for compile and compile-file. It
is my belief that whether to override or not must be controlled through an
argument to the compile functions, with the default being to override.
Otherwise, all existing code which makes use of the compile functions must
be modified to protect itself by wrapping a
(with-compilation-unit (:override t) ...) around the calls to the compiler.
Consider a stream system built on an object system which will compose and
compile functions on the fly on an as needed basis. It would be very strange
for the functions so generated while doing file io for the user's compile-file
to have any relationship with said compile-file.
I agree with your position that implementation-dependent extensions must be
explicitly requested.
kab
-------
∂13-Mar-89 1501 CL-Compiler-mailer Issue DEFINE-OPTIMIZER
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:01:17 PST
Date: Sun 12 Mar 89 16:02:34-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue DEFINE-OPTIMIZER
To: kmp@SCRC-STONY-BROOK.ARPA
cc: cperdue@SUN.COM, cl-compiler@SAIL.STANFORD.EDU, iim%ECLA@ECLC.USC.EDU
Message-ID: <12477530580.30.IIM@ECLA.USC.EDU>
I think you may have gotten the sense of Cris' INLINE comment wrong. I
believe what he was suggesting is that NOTINLINE declarations should inhibit
optimizers, a position I agree with. I also think it would be better to
specify the behavior when both an optimizer and an inline are present, rather
than leaving it 'unspecified but harmless'. I'd suggest that optimizers have
precedence. The rational is that this allows an optimizer to look for
special patterns in the arguments, and to defer to the inline if it doesn't
find them. Of course, there's the problem that the compiler might then ignore
the inline.
I agree with you that OPTIMIZER-FUNCTION is a bad idea. I think the main
problem is that it spells trouble for implementations which want to support
multiple optimizers for the same function.
kab
-------
∂13-Mar-89 1501 CL-Compiler-mailer Issue PROCLAIM-ETC-IN-COMPILE-FILE
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:01:10 PST
Date: Sun 12 Mar 89 16:05:59-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue PROCLAIM-ETC-IN-COMPILE-FILE
To: cl-compiler@SAIL.STANFORD.EDU
cc: iim%ECLA@ECLC.USC.EDU
Message-ID: <12477531202.30.IIM@ECLA.USC.EDU>
Proposal YES violates the general approach we've been taking of trying to
limit side-effects on the local environment during compilation.
Proposal NO makes PROCLAIM virtually worthless.
Proposal NEW-MACRO -- While this matches up with other stuff we've been doing,
I'm concerned about two things. First, I really dislike the name DEFPROCLAIM.
This thing isn't defining anything! It sounds like something that modifies
the behavior of PROCLAIM, not something that actually makes a proclamation.
Second, I'm concerned about the cost to users. I think the statement that
"Under any of these proposals, some users would probably have to make minor
changes to their code."
is rather misleading for this case. There are a lot of PROCLAIMs out there.
For current practice, the IIM compiler has special top-level handling for
PROCLAIM when the argument is a constant. The information is recorded in the
remote environment.
kab
-------
∂13-Mar-89 1457 CL-Compiler-mailer Issue LOCALLY-TOP-LEVEL, v1
Received: from ECLC.USC.EDU by SAIL.Stanford.EDU with TCP; 13 Mar 89 14:57:25 PST
Date: Sat 11 Mar 89 19:34:07-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Subject: Issue LOCALLY-TOP-LEVEL, v1
To: Moon@SCRC-STONY-BROOK.ARPA
cc: cl-cleanup@SAIL.STANFORD.EDU, cl-compiler@SAIL.STANFORD.EDU,
iim%ECLA@ECLC.USC.EDU
Message-ID: <12477306947.30.IIM@ECLA.USC.EDU>
This issue arguably ought to be a compiler issue, rather than cleanup, since
the compiler people seem to be the ones currently mucking about with what we
mean by top-level. (Besides, Larry is overworked as it is :-)
More seriously, I support this idea, in part because of the frob example. This
kind of thing was one of the reasons I voted against the DECLARATION-SCOPE
proposals.
By the way, my notes from the Hawaii meeting say that we passed the NO-HOISTING
proposal, and that LIMITED-HOISTING was not even called to a vote.
kab
-------
∂13-Mar-89 1545 CL-Compiler-mailer Issue MACRO-ENVIRONMENT-EXTENT
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:44:47 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556182; Mon 13-Mar-89 18:41:47 EST
Date: Mon, 13 Mar 89 18:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue MACRO-ENVIRONMENT-EXTENT
To: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
cc: cl-compiler@SAIL.STANFORD.EDU, Moon@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <12477307405.30.IIM@ECLA.USC.EDU>
Message-ID: <19890313234142.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat 11 Mar 89 19:36:38-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
Your recent statement that you are convinced that CLOS made a mistake with
regard to environments has made me reconsider the problem, and I think I may be
convincable. I'm going to throw some thoughts your way to see if maybe we can
reach some definite, defendable, conclusions on the subject.
Right now, our implementation provides some functions for manipulating remote
environments without specifying the environment as an argument. These
functions work by referencing a special variable bound by the compiler.
Currently the only places it is legit to put calls to them is in the compiler
itself or in (eval-when (compile) ...) forms. It wouldn't be hard to arrange
for a compiler-like user program to be able to use these.
That's interesting, because that is exactly how I want to propose
things like the macroexpansion of defmethod should work. The fact that
your implementation already works this way gives me more confidence
that I've made the right choice.
It's a little confusing, because this issue is being simultaneously discussed
on cl-compiler, common-lisp-object-system, and in private mail. So if I say
something that seems totally off the wall, it might be that I'm assuming
you've seen something that was only sent to a different mailing list.
It is because these functions usually seem to be adequate for the job that I
think you might be right. The places where they currently don't work seem to
be precisely those places where somebody has said that a function (like
find-class) takes an environment argument just to distinguish between remote
and local environments.
Suppose we were to say that T is a special indicator for the remote null
lexical environment, just as NIL is a special indicator for the local null
lexical environment.
What I'm going to propose is nil for the local null lexical environment,
compile-file for the special environment the compile-file function uses
as a model of the load-time null lexical environment, and also a macroexpansion
environment can be used provided you are within its dynamic extent.
As I think you and I have both mentioned at various times, this could be
extended to allow other kinds of environments, for instance one that allows
hypothetical class setups that aren't in force in the running world. However
I don't want to propose that at this time; it can be an implementation extension
at present and maybe be standardized in some future standard.
Then find-class could be defined as
(defun find-class (name &optional (errorp t) env)
(cond ((and (environment-remote-p env)
<< look it up in the remote environment, in some special >>))
(<< look it up in the local environment >>)
(errorp (error ...))
(t nil)))
Right. environment-remote-p just has to accept the special symbol
compile-file as well as nil and macroexpansion environments.
To make this all fly we would have to say some things about when it is legit to
use T as an environment, but I don't think this is hard. Admitedly, people can
get strange bugs if they use it wrongly, but many of the same kinds of problems
can occur with passing around environments that are real data structures.
What I plan to say is that compile-file as an environment is valid only
inside of an (eval-when (compile) ...). I think that has just the right
behavior. Note that compile must be the -only- situation specified.
The one thing I'm concerned about is the use of a special to hold the
environment. I think its ok, as long as there is some specified way to bind it
and everybody who wants to do compile-file-like things uses that mechanism.
Some sort of with- construct, and don't even bother to document what the
special variable is, seems to me to be the right way to go. The only case I
can think of where this might be a problem is if somebody were trying to
distribute the work of their 'compilation' over multiple processes/processors,
and I think any system that would support doing such a thing is likely to have
some mechanism for doing what's needed, like being able to have process trees,
with children inheriting bindings from parents.
I don't think we should specify that it's a special variable, only that
the functions such as find-class that deal with this thing know the
implementation-dependent way to find it.
Note that this does throw away the possibility of operating on multiple
distinct remote environements at the same time. I mentioned this in a message
a while back to the small group discussing remote environment issues. Is that
so bad? Maybe we'll just have to say "Tough. You can't do it."
Not entirely, see possible future proposal mentioned above. What this really
does is to decouple the multiple remote environments idea from macroexpansion
environments.
Note that I read your message after sending out version 3 of
syntactic-environment-access, which includes some stuff that goes off in a
different direction from what I think you are suggesting. If we can agree to
something like what I'm describing here, that proposal will have to be yanked
around to a somewhat different path.
Fortunately I haven't read that proposal yet. I'll postpone reading it for
a few days.
∂13-Mar-89 1557 CL-Cleanup-mailer Issue LOCALLY-TOP-LEVEL, v1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:55:08 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556199; Mon 13-Mar-89 18:51:17 EST
Date: Mon, 13 Mar 89 18:51 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue LOCALLY-TOP-LEVEL, v1
To: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
cc: cl-cleanup@SAIL.STANFORD.EDU, cl-compiler@SAIL.STANFORD.EDU
In-Reply-To: <12477306947.30.IIM@ECLA.USC.EDU>
Message-ID: <19890313235118.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sat 11 Mar 89 19:34:07-PST
From: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>
This issue arguably ought to be a compiler issue, rather than cleanup, since
the compiler people seem to be the ones currently mucking about with what we
mean by top-level. (Besides, Larry is overworked as it is :-)
I may have sent it to the wrong committee by mistake. If either Sandra or
Larry instructs me to send it to the other committee, I'll do so forthwith.
More seriously, I support this idea, in part because of the frob example. This
kind of thing was one of the reasons I voted against the DECLARATION-SCOPE
proposals.
By the way, my notes from the Hawaii meeting say that we passed the NO-HOISTING
proposal, and that LIMITED-HOISTING was not even called to a vote.
You're right, I copied down the wrong proposal name. What I said about
it is true of the NO-HOISTING proposal but false of the LIMITED-HOISTING
proposal. This needs to be fixed before it's distributed more widely.
∂13-Mar-89 1500 CL-Compiler-mailer Re: issue SAFE-CODE, version 1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 13 Mar 89 15:00:01 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556127; Mon 13-Mar-89 17:57:16 EST
Date: Mon, 13 Mar 89 17:56 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue SAFE-CODE, version 1
To: ROSENKING@A.ISI.EDU
cc: cl-compiler@SAIL.STANFORD.EDU
In-Reply-To: <[A.ISI.EDU]13-Mar-89 16:14:03.ROSENKING>
Message-ID: <890313175657.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
The concept of ``safe code'' is already defined by the issue
ERROR-TERMINOLOGY. It is needed in order to define the term ``should
signal.'' See that proposal for details.
SAFE-CODE is only the issue name, it is not the name of any
proposed feature.
The only issue here is whether the abstract term ``safe code''
in Kathy's ERROR-TERMINOLOGY has any mapping to what you do
in your code. This issue seeks to define that at least in the
situation where you ask for (OPTIMIZE (SAFETY 3)), you are asking
for safe code.
If you agree that saying (OPTIMIZE (SAFETY 3)) is asking for your
code to be safe, then I think you should support this proposal.
If what you are worried about is whether the default in the absence
of such a declaration is `safe' or `unsafe' -- a separate issue
(now before CL-Cleanup) will address this. I believe the issue
is called OPTIMIZE-SAFETY.
In retrospect, it's clear I should not have split the two issues
but at the time it seemed like the right thing.
∂13-Mar-89 1647 CL-Compiler-mailer Re: issue DEFINE-OPTIMIZER, version 5
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 16:47:05 PST
Received: from snail.Sun.COM by Sun.COM (4.1/SMI-4.0)
id AA27387; Mon, 13 Mar 89 16:47:48 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA06344; Mon, 13 Mar 89 16:44:04 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA24118; Mon, 13 Mar 89 16:47:36 PST
Date: Mon, 13 Mar 89 16:47:36 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903140047.AA24118@clam.sun.com>
To: cl-compiler@sail.stanford.edu
Subject: Re: issue DEFINE-OPTIMIZER, version 5
I think the spec for this is going to have to hedge on
whether optimizers defined in this way affect functions
in the LISP package. Perhaps it would be acceptable
to say, "Defining an optimizer for a function in the LISP
package may affect some, all, or no calls on that function."
Barrett suggests that optimizers need to have precedence over
INLINE for a function. This must surely be true. Are we
to tell users to not declare a function INLINE because that
might calls not to be optimized?
Regarding the accessor primitive, the problems with that
are not much harder than the problems with DEFINE-OPTIMIZER.
For example, if it is permitted to define an optimizer on a function
in package LISP, then we specify that those are all NIL
as supplied by the LISP vendor.
The operations on optimizers are incomplete in the current proposal,
and adding a suitable primitive would fix that problem and let
users write portable code for testing for an optimizer, copying,
accessing, and moving.
I'm not at all sold on the argument that a primitive would
interfere with an implementation that wishes to have multiple
optimizers for the same function. I see nothing in the current
proposal to support that capability.
∂13-Mar-89 1655 CL-Compiler-mailer Re: issue PROCLAIM-ETC-IN-COMPILE-FILE, version 3
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Mar 89 16:55:11 PST
Received: by ti.com id AA04177; Mon, 13 Mar 89 18:52:42 CST
Received: from Kelvin by tilde id AA08146; Mon, 13 Mar 89 18:35:57 CST
Message-Id: <2814827699-4227621@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 13 Mar 89 18:34:59 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu
Subject: Re: issue PROCLAIM-ETC-IN-COMPILE-FILE, version 3
In-Reply-To: Msg of Sat, 11 Mar 89 13:41:24 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Proposal PROCLAIM-ETC-IN-COMPILE-FILE:YES:
>
> Require COMPILE-FILE to treat top-level calls to PROCLAIM as if they
> were wrapped in an (EVAL-WHEN (COMPILE LOAD EVAL) ...).
This is my preference.
> Proposal PROCLAIM-ETC-IN-COMPILE-FILE:NO:
>
> Clarify that calls to PROCLAIM should be treated the same as any
> other function call. Users should wrap an explicit EVAL-WHEN around
> top-level calls to PROCLAIM if they want them to affect compilation.
This means that the EVAL-WHEN would be needed on nearly every use of
PROCLAIM, which goes against the model that EVAL-WHEN is only needed for
exceptional situations. (Page 69 of CLtL says about EVAL-WHEN that "Its
uses are relatively esoteric.")
> Proposal PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO:
>
> Add a new macro:
>
> DEFPROCLAIM &rest decl-specs [Macro]
>
> This macro PROCLAIMs the given <decl-specs>, which are not
> evaluated. If a call to this macro appears at top-level in a file
> being processed by the file compiler, the proclamations are also
> made at compile-time. As with other defining macros, it is
> unspecified whether or not the compile-time side-effects of a
> DEFPROCLAIM persist after the file has been compiled.
I don't like this name because the convention is that macros with names
beginning with DEF... are used to define things, with the name of the
thing being defined appearing as the first argument or as part of the
first argument. DEFPROCLAIM doesn't define anything. I think this
would also confuse users because it has the same syntax as DECLARE, but
the two can't be used interchangeably. It makes me wonder whether we
should just permit top-level DECLAREs, but then _it_ would need special
handling by the compiler since a macro definition would confuse the
semantics of local declarations, so you don't win.
> Cost to users:
>
> For proposal YES, users would have no way to suppress compile-time
> evaluation of a top-level call to PROCLAIM. Wrapping it in an
> (EVAL-WHEN (EVAL LOAD)...) wouldn't work under the model of how
> EVAL-WHEN works in proposal EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL.
How about (LET () (PROCLAIM ...)) ?
∂13-Mar-89 1703 CL-Compiler-mailer **DRAFT** issue DEFCONSTANT-NOT-WIRED, version 6
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 17:03:00 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 13 Mar 89 19:59:22 EST
Date: Mon, 13 Mar 89 20:00 EST
From: Barry Margolin <barmar@Think.COM>
Subject: **DRAFT** issue DEFCONSTANT-NOT-WIRED, version 6
To: cl-compiler@sail.stanford.edu
In-Reply-To: <8903132328.AA02557@defun.utah.edu>
Message-Id: <19890314010044.2.BARMAR@OCCAM.THINK.COM>
Date: Mon, 13 Mar 89 16:28:37 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Forum: Compiler
Issue: DEFCONSTANT-NOT-WIRED
I have a terminology: use the term READ-ONLY in place of CONSTANT in the
suggested declaration, DEFINE-VARIABLE, etc. The term "constant" should
be reserved for things that are truly constant (pi, e,
number-of-bits-per-word, etc.); this is why they can be wired into code.
A symbol whose value might change due to external influences but which
should not be changeable by the user program is simply "read only".
It's like PROM -- the program can't change the value of a location, but
the user can plug in a new chip with a new value.
I like the idea of a DEF-READ-ONLY, which could expand into a DEFVAR
followed by a (PROCLAIM '(READ-ONLY <var>)). I also think that there
should be a NOT-READ-ONLY declaration; this way, if the constant needs
to be changed for some reason (e.g. reloading the file containing the
DEF-READ-ONLY form) there is a mechanism for turning off checking of
attempts to modify read-only variables. I'm not wedded to this idea,
though, because it means that read-only variables could not be put in
ROM (and depending on the system architecture, it could also prevent
them from being put in read-only memory segments).
barmar
∂13-Mar-89 1643 X3J13-mailer issue COMPILER-LET-CONFUSION, version 7
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 16:43:27 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 13 Mar 89 19:39:46 EST
Date: Mon, 13 Mar 89 19:41 EST
From: Barry Margolin <barmar@Think.COM>
Subject: issue COMPILER-LET-CONFUSION, version 7
To: cl-compiler@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132314.AA02546@defun.utah.edu>
Message-Id: <19890314004109.1.BARMAR@OCCAM.THINK.COM>
Date: Mon, 13 Mar 89 16:14:26 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
In interpreters which do not do a semantic-prepass, it is necessary
to fully macroexpand the body. Assuming the presence of a
SYSTEM::MACROEXPAND-ALL primitive, the definition of COMPILER-LET
could look like:
(DEFMACRO COMPILER-LET (BINDINGS &BODY FORMS &ENVIRONMENT ENV)
(SETQ BINDINGS ;; Assure no non-atom bindings
(MAPCAR #'(LAMBDA (BINDING)
(IF (ATOM BINDING) (LIST BINDING) BINDING))
BINDINGS))
(PROGV (MAPCAR #'CAR BINDINGS)
(MAPCAR #'CDR BINDINGS)
(SYSTEM::MACROEXPAND-ALL `(PROGN ,@FORMS) ENV)))
Modulo some bugs in the code. Shouldn't the second-to-last line be:
(MAPCAR #'(LAMBDA (BINDING)
(eval (CaDR BINDING)))
BINDINGS)
(my additions are in lowercase)?
barmar
∂13-Mar-89 1730 CL-Compiler-mailer issue DEFINE-OPTIMIZER, version 5
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 17:29:43 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 13 Mar 89 20:26:02 EST
Date: Mon, 13 Mar 89 20:27 EST
From: Barry Margolin <barmar@Think.COM>
Subject: issue DEFINE-OPTIMIZER, version 5
To: cl-compiler@sail.stanford.edu
In-Reply-To: <8903132331.AA02562@defun.utah.edu>
Message-Id: <19890314012719.3.BARMAR@OCCAM.THINK.COM>
While I like the proposal in general, I don't think it's appropriate to
add this to the language at this time. If most Lisp vendors are in
favor of it, though, my objection is pretty weak. But there's still the
editorial issue of adding it to the standard. I don't really think it's
worth it for the first version of the standard.
Also, I don't see a whole lot of value in portable optimizers. Yes, the
Macsyma example is a good one, but the real value of optimizers comes
when they translate into calls to extra fast, internal functions.
Portable optimizers can't do this, and non-portable optimizers don't
need to be defined using a portable mechanism.
barmar
∂13-Mar-89 1737 CL-Compiler-mailer Re: Issue: LOAD-OBJECTS (Version 3)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Mar 89 17:36:36 PST
Received: by ti.com id AA04345; Mon, 13 Mar 89 19:33:22 CST
Received: from Kelvin by tilde id AA09130; Mon, 13 Mar 89 19:25:26 CST
Message-Id: <2814830669-4406064@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 13 Mar 89 19:24:29 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Richard P. Gabriel" <rpg@lucid.com>
Cc: CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
In-Reply-To: Msg of Sat, 11 Mar 89 16:46:51 PST from Richard P. Gabriel <rpg@lucid.com>
> I was a little surprised to see that this proposal talks about load
> forms instead of load functions (which goes to show how much I've been
> paying attention).
One advantage of sticking with the load form approach is that it has
already been implemented and demonstrated to work.
> I think people will find the macro approach (the current approach)
> baroque, partly because the approach is best understood by thinking of
> an input phase to a compiler or some such program, rather than by
> thinking about an output phase when everything has already been supposedly
> created. For example, when I read the current proposal, I imagined it
> in the FASDUMP phase.
Think of it as input to the loader.
> One drawback of my proposal is that the function approach is a little
> more verbose in some cases. I also think it is subject to more
> circularity errors by novices than the macro approach. On the other
> hand, the functional approach makes one think about the issues a
> little harder when writing the code, which is possibly a good thing.
This sounds like a clear disadvantage, without a clear advantage.
> ;; Example 3 (expanded to do a hairy thing that cannot be easily done
> ;; in the macro approach).
...
> One can imagine the shared lexical environment of the creator and initializer
> being a high-bandwidth channel for information, such as the important
> information passed in the above example.
This example illustrates the following assumptions about dumping
constants:
1. Lexical closures can be dumped and loaded.
2. Two closures that share the same environment at compile-time will
also share the same environment at load time.
3. The lexical environment as reconstructed by the loader is not
write-protected (meaning that closures are not really constants).
4. It is safe to assume that none of the closed-over variables are
changed between the time the first closure is dumped and the time
the last closure that shares that environment is dumped.
It could be argued that all of these would be desirable, but I think
it's a little late to be biting off that much.
∂13-Mar-89 1754 CL-Compiler-mailer Re: Issue: LOAD-OBJECTS (Version 3)
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Mar 89 17:54:05 PST
Received: by ti.com id AA04437; Mon, 13 Mar 89 19:49:49 CST
Received: from Kelvin by tilde id AA09309; Mon, 13 Mar 89 19:36:34 CST
Message-Id: <2814831335-4446073@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 13 Mar 89 19:35:35 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: jrose@Sun.COM (John Rose)
Cc: sandra%defun@cs.utah.edu, rpg@lucid.com, CL-Cleanup@sail.stanford.edu,
CL-Compiler@sail.stanford.edu
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
In-Reply-To: Msg of Mon, 13 Mar 89 11:35:38 PST from jrose@Sun.COM (John Rose)
> One is that this scheme cannot support circular constants.
I second the objection.
> By the way, I also share rpg's preference for functions over forms,
> because functions are parametrized naturally via captured lexicals,
> whereas you've got to use backquote to parametrize forms, a more
> error-prone technique.
>
> Here's an example which suggests the relative conciseness of the techniques:
>
> ;; Using functions:
> (defmethod make-load-form ((x myclass))
> (let ((p <pval>) (q <qval>) (r <rval>))
> #'(lambda () <code>)))
>
> ;; Using forms:
> (defmethod make-load-form ((x myclass))
> `(let ((p ',<pval>) (q ',<qval>) (r ',<rval>))
> <code>))
I don't think that's a completely fair comparison because the LET is
required for the function approach, but would usually not be needed with
the forms approach:
;; Using functions:
(defmethod make-load-form ((x myclass))
(let ((p <pval>) (q <qval>) (r <rval>))
#'(lambda () (make-mine p q r))))
;; Using forms:
(defmethod make-load-form ((x myclass))
`(make-mine ',<pval> ',<qval> ',<rval>))
This is a very simple use of back-quote, while the function approach is
error-prone because it would be too easy to forget to do the LET
binding.
∂13-Mar-89 1809 CL-Compiler-mailer **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 13 Mar 89 18:09:14 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Mon, 13 Mar 89 21:05:31 EST
Date: Mon, 13 Mar 89 21:06 EST
From: Barry Margolin <barmar@Think.COM>
Subject: **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
To: cl-compiler@sail.stanford.edu
In-Reply-To: <8903132355.AA02585@defun.utah.edu>
Message-Id: <19890314020643.4.BARMAR@OCCAM.THINK.COM>
I'm not really sure how I feel about this issue. My gut reaction is
that only dynamic extent should really be necessary.
In any case, if DYNAMIC-WITH-COPIER is seriously proposed, I'd prefer a
different name for the function. A function COPY-xxx that is permitted
to return its argument instead of a copy seems poorly named (do we have
any other such functions?). COPY-ENVIRONMENT-IF-NECESSARY is better,
since it explicitly mentions the conditional nature, but it's pretty
long (but how often will it be used?). INDEFINITE-EXTENT-ENVIRONMENT is
also a good name, but just as long.
Maybe a declaration is the right thing for this, as in the
DYNAMIC-EXTENT cleanup proposal. I'd prefer dynamic extent to be the
default, with a declaration to request indefinite extent since that is
less commonly needed. Implementations may ignore the declaration, but
they must then always provide indefinite extent. A simpler proposal
would be to make indefinite extent the default, and then the
DYNAMIC-EXTENT cleanup proposal would permit programmers to explicitly
declare dynamic environments.
barmar
∂13-Mar-89 1836 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
Received: from ti.com by SAIL.Stanford.EDU with TCP; 13 Mar 89 18:35:58 PST
Received: by ti.com id AA04725; Mon, 13 Mar 89 20:33:56 CST
Received: from Kelvin by tilde id AA10072; Mon, 13 Mar 89 20:28:54 CST
Message-Id: <2814834476-4634758@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Mon, 13 Mar 89 20:27:56 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu, "Kim A. Barrett" <IIM@ECLA.USC.EDU>
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
In-Reply-To: Msg of Sun, 12 Mar 89 10:59:59 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)
Either alternative SMALL or LARGE is reasonable, but I don't think that
MEDIUM is viable because ENVIRONMENT-REMOTE-P and
WITH-REMOTE-ENVIRONMENT aren't very useful if you don't have
ENVIRONMENT-PROPERTY. ENVIRONMENT-REMOTE-P might be useful in
conjunction with FIND-CLASS, but the use of environments by FIND-CLASS
seems to be in question now.
> Using SETF of ENVIRONMENT-PROPERTY affects all environments which
> refer to the same environment model. In particular, if ENV is a
> local environment then all local environments are affected, ...
Need to make clear that this affects the global environment, not just
all local environments.
> ... while if
> ENV is a remote environment, then all environments refering to the
> same remote environment model as the argument are affected.
"same model" is not a defined term; would be more precise to say all
environments which inherit from the same remote environment.
> An possible alternative syntax for WITH-REMOTE-ENVIRONMENT might be
> WITH-REMOTE-ENVIRONMENT (var &key) &body body
> Can anyone suggest candidates for keyword options? We could do this
> even if we can't think of any immediately, leaving room for
> implementation-specific extensions. One candidate option that some
> implementations might want would be to specify a target machine for
> the compilation.
Yes, I think that would be a good idea. For cross-compilation, I would
want the COMPILE-FILE remote environment to inherit from a remote
environment representing the target machine. How about a :PARENT option
for specifying a parent environment?
∂14-Mar-89 0644 CL-Compiler-mailer issue DEFINE-OPTIMIZER, version 5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 06:44:10 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556489; Tue 14-Mar-89 09:41:41 EST
Date: Tue, 14 Mar 89 09:41 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFINE-OPTIMIZER, version 5
To: barmar@Think.COM
cc: cl-compiler@sail.stanford.edu
In-Reply-To: <19890314012719.3.BARMAR@OCCAM.THINK.COM>
Message-ID: <890314094133.9.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Mon, 13 Mar 89 20:27 EST
From: Barry Margolin <barmar@Think.COM>
... the real value of optimizers comes when they translate into calls
to extra fast, internal functions. ...
What makes you say that you can't translate particular calls to
a user function into extra fast (even constant-time!) algorithms
based on domain-specific knowledge?
Portable optimizers can't do this, and non-portable optimizers don't
need to be defined using a portable mechanism.
I believe this claim is unsubstantiated and unsubstantiable. In many
implementations, internal functions have no special property that user
programs do not. In some cases, that makes the optimizers that much
more important since most internal functions run a constant factor
faster, but do not have any algorithmic leverage over user programs.
Optimizers are potentially able to do much better than built-in
optimizations because they can use domain-specific information that
is beyond the power of even the proverbial SCC (Sufficiently Clever
Compiler).
Optimizers have been around for a -long- time. They are not new
technology. If we cannot adopt at least this much this time, I see
no reason why for CL 2000 we won't have the exact same arguments
raised and we -still- won't get anything. On the other hand, if we
adopt them now we get years of field testing, and next time there
will be a lot of users with suggestions about how to improve them.
Some progress must be made incrementally -- but no progress is made
if the increment is zero.
The risks are very low. This proposal already says the optimizer
function has to be semantics-preserving, and that it might never be
called. It's hard to see how that can go wrong.
For so little cost and so much potential gain, I think it is worth any
associated risk.
∂14-Mar-89 0646 CL-Compiler-mailer issue COMPILER-LET-CONFUSION, version 7
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 06:46:46 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556490; Tue 14-Mar-89 09:44:20 EST
Date: Tue, 14 Mar 89 09:44 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-LET-CONFUSION, version 7
To: barmar@Think.COM
cc: cl-compiler@sail.stanford.edu
In-Reply-To: <19890314004109.1.BARMAR@OCCAM.THINK.COM>
Message-ID: <890314094413.0.KMP@BOBOLINK.SCRC.Symbolics.COM>
[X3J13 removed.]
Date: Mon, 13 Mar 89 19:41 EST
From: Barry Margolin <barmar@Think.COM>
Date: Mon, 13 Mar 89 16:14:26 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
(DEFMACRO COMPILER-LET (BINDINGS &BODY FORMS &ENVIRONMENT ENV)
...
(PROGV (MAPCAR #'CAR BINDINGS)
(MAPCAR #'CDR BINDINGS)
(SYSTEM::MACROEXPAND-ALL `(PROGN ,@FORMS) ENV)))
Modulo some bugs in the code. Shouldn't the second-to-last line be:
(MAPCAR #'(LAMBDA (BINDING) (eval (CaDR BINDING))) BINDINGS)
...?
Yes.
∂14-Mar-89 0651 CL-Compiler-mailer Re: issue PROCLAIM-ETC-IN-COMPILE-FILE, version 3
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 06:51:37 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556493; Tue 14-Mar-89 09:47:29 EST
Date: Tue, 14 Mar 89 09:47 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue PROCLAIM-ETC-IN-COMPILE-FILE, version 3
To: Gray@DSG.CSC.TI.COM, sandra%defun@CS.Utah.EDU
cc: CL-Compiler@SAIL.Stanford.EDU
In-Reply-To: <2814827699-4227621@Kelvin>
Message-ID: <890314094721.1.KMP@BOBOLINK.SCRC.Symbolics.COM>
Date: Mon, 13 Mar 89 18:34:59 CST
From: David N Gray <Gray@DSG.csc.ti.com>
...
> Cost to users:
>
> For proposal YES, users would have no way to suppress compile-time
> evaluation of a top-level call to PROCLAIM. Wrapping it in an
> (EVAL-WHEN (EVAL LOAD)...) wouldn't work under the model of how
> EVAL-WHEN works in proposal EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL.
How about (LET () (PROCLAIM ...)) ?
Actually, I often use (EVAL '...) to defer evaluation to load time.
I have to say, though, that I don't know of any reason why I would
use PROCLAIM at toplevel and not want the compiler to notice it.
I can't remember this ever coming up.
∂14-Mar-89 0702 CL-Compiler-mailer Re: issue MACRO-CACHING, version 2
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 07:02:35 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 06:51:59 PST
Date: 14 Mar 89 06:51 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue MACRO-CACHING, version 2
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
Mon, 13 Mar 89 09:47:38 -0700
To: cl-compiler@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890314-065159-22429@Xerox>
I think we would be better off just deprecating *MACROEXPAND-HOOK* or
removing the suggestions that it might be used for caching macro expansions
and just suggesting that it might be used for "debugging" purposes. Most of
the rest of this belongs in an "implementation note" or something, rather
than in the "spec" for *MACROEXPAND-HOOK*, doesn't it?
!
In fact, when I did macro caching for Xerox Common Lisp, I found that I had
to not do caching when there were any COMPILER-LETs in force, too.
The guard was:
Don't cache if you're not in the interpreter
(e.g., a "code-walk" or a "compiler" environment)
Don't cache if there are any macros/functions
lexically defined.
Don't cache if inside a COMPILER-LET.
*Any* redefinition of any function or variable clears the cache.
This is still a heuristic, of course, since there are legitimate ways of
changing something that a macro-expansion depends on that won't get
noticed.
∂14-Mar-89 0738 CL-Compiler-mailer Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 14 Mar 89 07:38:33 PST
Received: from relay2.cs.net by RELAY.CS.NET id ac25718; 14 Mar 89 10:16 EST
Received: from draper.com by RELAY.CS.NET id ae09120; 14 Mar 89 10:11 EST
Date: Tue, 14 Mar 89 08:14 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE
To: cl-compiler@SAIL.STANFORD.EDU
X-VMS-To: CL-COMPILER,SEB1525
> I don't like this name because the convention is that macros with names
> beginning with DEF... are used to define things, with the name of the
> thing being defined appearing as the first argument or as part of the
> first argument. DEFPROCLAIM doesn't define anything. I think this
> would also confuse users because it has the same syntax as DECLARE, but
> the two can't be used interchangeably. It makes me wonder whether we
> should just permit top-level DECLAREs, but then _it_ would need special
> handling by the compiler since a macro definition would confuse the
> semantics of local declarations, so you don't win.
I don't understand the last sentence. What kind of macro definition?
Can you give an example?
I never understood why PROCLAIM was created in the first place, and why
it was decided ages ago that top-level DECLARE was no good. Since DECLARE
is a special form, the compiler is free to do anything at all with it, and
we don't have to treat any functions specially at top level. Who does
(PROCLAIM <function-call-or-variable>) anyway?
∂14-Mar-89 0938 CL-Compiler-mailer issue COMPILER-LET-CONFUSION, version 7
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 09:37:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556615; Tue 14-Mar-89 12:35:04 EST
Date: Tue, 14 Mar 89 12:35 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-LET-CONFUSION, version 7
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132314.AA02546@defun.utah.edu>
Message-ID: <19890314173505.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I generally favor the COMPILER-LET-CONFUSION:REPAIR proposal, however
I have a couple of comments and questions. Also of course I would want
to see the typo that BarMar found fixed.
What is the interaction between proposals COMPILER-LET-CONFUSION
and DEFINE-OPTIMIZER? Neither proposal says anything about that
as far as I can see. I believe the body of a optimizer must be
executed in the same dynamic environment as the body of a macro.
Cost to Implementors:
In interpreters which do not do a semantic-prepass, it is necessary
to fully macroexpand the body.
This is not true. A possible implementation technique for such
interpreters, in fact the one I would use, is to save the COMPILER-LET
bindings in a slot in the interpreter's lexical environment in the form
of an alist, and to make the MACROEXPAND-1 function bind those bindings
with PROGV around its call to the macroexpander. Using this technique
instead of fully macroexpanding the body deals with some of the
objections to the REPAIR proposal, I believe. Also promoting this
technique in the proposal would remove the need for the discussion
section to address the side-issue of whether code analyzing programs can
or cannot be written portably (an important issue in its own right, but
not part this one).
Current Practice:
Some implementations have implemented the description in CLtL.
Users of those implementations (quite reasonably) can't figure how to
use COMPILER-LET and so don't use it much.
Some implementations (the ones from which COMPILER-LET originally came)
continue to use their pre-CLtL semantics. These semantics are useful, though
incompatible with CLtL (which they largely consider to simply be in error).
Could you be more explicit about this? I was unable to figure out what you
are talking about, even after twice reading the introductory portion of the
proposal and the writeup in CLtL. I believe Symbolics Genera is one of those
implementations from which COMPILER-LET originally came and at the same time
implements COMPILER-LET exactly as CLtL specifies, so I must be missing some
important distinction. I'd like to see a precise description of these two
competing semantics and I'd also like to know which, if either, of them is
compatible with the REPAIR proposal.
∂14-Mar-89 0956 CL-Compiler-mailer issue DEFINE-OPTIMIZER, version 5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 09:56:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556621; Tue 14-Mar-89 12:54:02 EST
Date: Tue, 14 Mar 89 12:54 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFINE-OPTIMIZER, version 5
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132331.AA02562@defun.utah.edu>
Message-ID: <19890314175403.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I generally like DEFINE-OPTIMIZER:NEW-FACILITY, but I would like
to suggest a couple of changes.
I'm not a fan of documentation strings, but shouldn't DEFINE-OPTIMIZER
allow them? Was their omission accidental or intentional?
Instead of returning two values from the body, I suggest returning one
value, or NIL to decline to optimize. If an optimizer wishes to
optimize into a form whose result is NIL, it should return (QUOTE NIL).
After all, if it wishes to optimize into a form whose result is FOO, it
has to return (QUOTE FOO), not FOO. The two values returned by
OPTIMIZE-EXPRESSION-1 are okay, since they are compatible with the two
values returned by MACROEXPAND-1. A reasonable alternative would be to
eliminate the two values at all levels, and also eliminate the special
casing of NIL, and simply specify that one declines to optimize by
returning the original form (compared with EQ). This will work but is
slightly more awkward for the optimizer writer, since &WHOLE would
have to be used. I'd accept this alternative if more people are in
favor of it, but I prefer special-casing NIL. I'd greatly prefer either
of those alternatives over what the proposal says now.
It isn't made clear whether OPTIMIZE-EXPRESSION returns one value
or two. It should be consistent with OPTIMIZE-EXPRESSION-1.
Using FLET and MACROLET shadow...
I assume it was only accidental that LABELS, GENERIC-LABELS, and
GENERIC-FLET were omitted from this list. I am unable to figure
out whether WITH-ADDED-METHODS should be included in this list
or not; I suspect not.
The similar Symbolics Genera facility allows more than one optimizer
to be defined for a given function; the optimizers are invoked in
unspecified order until one succeeds. This feature is actually
used, however I think it is okay to leave it out.
I agree with Barrett's comments quoted in the discussion section.
I'd like to see the proposal amended the way he suggests.
∂14-Mar-89 1005 CL-Compiler-mailer issue WITH-COMPILATION-UNIT, version 3
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 10:05:29 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556623; Tue 14-Mar-89 13:03:02 EST
Date: Tue, 14 Mar 89 13:03 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue WITH-COMPILATION-UNIT, version 3
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903140025.AA02634@defun.utah.edu>
Message-ID: <19890314180303.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I oppose this because I don't think it's finished, however I expect I
would support it if it were finished. It may be that the amount of work
required to finish this is small and the proposal just needs amending.
I don't think it's acceptable to have something like this if its effect
is only defined for warnings, and its effect on compile-time
proclamations, compile-time macro definitions, compile-time defconstant
definitions, compile-time optimizer definitions, compile-time type
definitions, compile-time setf definitions, and compile-time CLOS
definitions is left unspecified.
I think lumping COMPILE and COMPILE-FILE together here reflects
confusion. COMPILE and COMPILE-FILE have very little to do with each
other, and I think it's clear that COMPILE should not be affected in any
way by WITH-COMPILATION-UNIT. Having COMPILE affected by
WITH-COMPILATION-UNIT is as unreasonable as having MACROEXPAND affected
by WITH-COMPILATION-UNIT, if you ask me. I think removing COMPILE would
address Barrett's complaint in the discussion section; that is, I think
having COMPILE-FILE not override an enclosing WITH-COMPILATION-UNIT is
correct.
∂14-Mar-89 1009 CL-Compiler-mailer Re: issue COMPILER-LET-CONFUSION, version 7
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Mar 89 10:09:01 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA05592; Tue, 14 Mar 89 11:05:43 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA03474; Tue, 14 Mar 89 11:05:23 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903141805.AA03474@defun.utah.edu>
Date: Tue, 14 Mar 89 11:05:22 MST
Subject: Re: issue COMPILER-LET-CONFUSION, version 7
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: kmp@stony-brook.scrc.symbolics.com, cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 14 Mar 89 12:35 EST
> Date: Tue, 14 Mar 89 12:35 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> What is the interaction between proposals COMPILER-LET-CONFUSION
> and DEFINE-OPTIMIZER? Neither proposal says anything about that
> as far as I can see. I believe the body of a optimizer must be
> executed in the same dynamic environment as the body of a macro.
I think you're right about this.
> A possible implementation technique for such
> interpreters, in fact the one I would use, is to save the COMPILER-LET
> bindings in a slot in the interpreter's lexical environment in the form
> of an alist, and to make the MACROEXPAND-1 function bind those bindings
> with PROGV around its call to the macroexpander. Using this technique
> instead of fully macroexpanding the body deals with some of the
> objections to the REPAIR proposal, I believe. Also promoting this
> technique in the proposal would remove the need for the discussion
> section to address the side-issue of whether code analyzing programs can
> or cannot be written portably (an important issue in its own right, but
> not part this one).
An earlier version of this issue actually contained a proposal
REDEFINE that suggested doing this very thing. However, it didn't
seem like it had much support, and it had the problem that it could be
subverted by programs that call the MACRO-FUNCTION directly.
Kent mentioned a similar implementation technique in his first
iteration on proposal REPAIR (in which it was the responsibility of
the compiler or interpreter to bind the variables before calling
MACROEXPAND-1). I removed it partly because it would be even easier
to subvert than the earlier REDEFINE proposal, and partly because it
looked like we were going to get bogged down in a discussion of
side-effecting the variables.
> Current Practice:
>
> Some implementations (the ones from which COMPILER-LET originally came)
> continue to use their pre-CLtL semantics. These semantics are useful, though
> incompatible with CLtL (which they largely consider to simply be in error).
>
> Could you be more explicit about this?
Kent, since this is your language, can you do something about this? This
is the second complaint we've gotten about this particular statement.
I must admit that I am also not sure how the pre-CLtL semantics differ
from the CLtL semantics.
-Sandra
-------
∂14-Mar-89 1053 CL-Compiler-mailer Re: issue WITH-COMPILATION-UNIT, version 3
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Mar 89 10:53:34 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA07757; Tue, 14 Mar 89 11:50:22 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA03524; Tue, 14 Mar 89 11:50:01 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903141850.AA03524@defun.utah.edu>
Date: Tue, 14 Mar 89 11:49:59 MST
Subject: Re: issue WITH-COMPILATION-UNIT, version 3
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: kmp@stony-brook.scrc.symbolics.com, cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 14 Mar 89 13:03 EST
> Date: Tue, 14 Mar 89 13:03 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> I don't think it's acceptable to have something like this if its effect
> is only defined for warnings, and its effect on compile-time
> proclamations, compile-time macro definitions, compile-time defconstant
> definitions, compile-time optimizer definitions, compile-time type
> definitions, compile-time setf definitions, and compile-time CLOS
> definitions is left unspecified.
This point has been raised before. Some of us have suggested that the
purpose of WITH-COMPILATION-UNIT is really to allow several files to
be treated as a unit sharing a single compilation environment, which
would include the information about undefined functions as well as all
the things you list above. However, the whole notion of compilation
environments is still pretty vague right now and I don't really blame
Kent for wanting to avoid the issue. I guess the real questions are,
can we firm up something on compilation environments in time to make
it into the standard; and if not, should we delay adding this feature
or define only the restricted form that Kent proposes?
> I think lumping COMPILE and COMPILE-FILE together here reflects
> confusion. COMPILE and COMPILE-FILE have very little to do with each
> other, and I think it's clear that COMPILE should not be affected in any
> way by WITH-COMPILATION-UNIT.
I agree with this. In particular, the extended notion of what this
form is for is sharing of what we have been calling a "remote"
environment across multiple calls to COMPILE-FILE. COMPILE always
uses a "local" environment and shouldn't be affected.
-Sandra
-------
∂14-Mar-89 1137 CL-Compiler-mailer issue DEFINE-OPTIMIZER, version 5
Received: from goldhill.com ([128.168.1.211]) by SAIL.Stanford.EDU with TCP; 14 Mar 89 11:37:09 PST
Received: by goldhill.com; Tue, 14 Mar 89 14:09:51 EST
Date: Tue, 14 Mar 89 14:09:51 EST
From: rpk@goldhill.com (Robert Krajewski)
Message-Id: <8903141909.AA09480@goldhill.com>
To: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 13 Mar 89 16:31:17 -0700 <8903132331.AA02562@defun.utah.edu>
Subject: issue DEFINE-OPTIMIZER, version 5
I think a portable optimizer definer is a fine idea. It's especially
useful for authors of Common Lisp-embedded subsystems that offer safe
access to their data structures in a development environment, but who
also wish to produce fast code for delivery. In such cases, an
optimizer should only run when unsafe code is desired.
Assuming that optimizers are invoked no matter what the compiletime
parameters (except maybe a switch to turn optimizers off), it would be
useful if the optimizer could make inquiries about OPTIMIZE SPEED,
SPACE, SAFETY, and so on. For example, Gold Hill Windows could turn a
call to WINDOW-X (a function which checks to see if its argument is a
window) into %WINDOW-X, a DEFSTRUCT-generated accessor which is
subject to further optimization. However, such an optimization is
warranted only if the unsafe code is desired. The optimization should
obtain only after an compile-time environment query is made.
I suppose the issue could be sidestepped if the subsystem advertises
compile-time parameters which are used by the optimizers.
(Another useful query is ``How many values are expected from this call ?''
but we'll leave all that for future standardization.)
Another issue: The documentation for the optimization for the facility
should make it clear that optimized form must preserve the Common
Lisp order-of-evaluation semantics of the form. In other words,
optimizers like
(define-optimizer foo (x y) `(better-foo ,y ,x))
are bad.
∂14-Mar-89 1217 CL-Compiler-mailer **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 12:17:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556715; Tue 14-Mar-89 15:09:52 EST
Date: Tue, 14 Mar 89 15:09 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue MACRO-ENVIRONMENT-EXTENT, version 3
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132355.AA02585@defun.utah.edu>
Message-ID: <19890314200952.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
I strongly favor MACRO-ENVIRONMENT-EXTENT:DYNAMIC over any of the other four.
∂14-Mar-89 1218 CL-Compiler-mailer Re: issue COMPILER-LET-CONFUSION, version 7
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 12:18:00 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556712; Tue 14-Mar-89 15:06:51 EST
Date: Tue, 14 Mar 89 15:06 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue COMPILER-LET-CONFUSION, version 7
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: kmp@STONY-BROOK.SCRC.Symbolics.COM, cl-compiler@sail.stanford.edu
In-Reply-To: <8903141805.AA03474@defun.utah.edu>
Message-ID: <19890314200643.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 14 Mar 89 11:05:22 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Date: Tue, 14 Mar 89 12:35 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> A possible implementation technique for such
> interpreters, in fact the one I would use, is to save the COMPILER-LET
> bindings in a slot in the interpreter's lexical environment in the form
> of an alist, and to make the MACROEXPAND-1 function bind those bindings
> with PROGV around its call to the macroexpander. Using this technique
> instead of fully macroexpanding the body deals with some of the
> objections to the REPAIR proposal, I believe. Also promoting this
> technique in the proposal would remove the need for the discussion
> section to address the side-issue of whether code analyzing programs can
> or cannot be written portably (an important issue in its own right, but
> not part this one).
An earlier version of this issue actually contained a proposal
REDEFINE that suggested doing this very thing. However, it didn't
seem like it had much support, and it had the problem that it could be
subverted by programs that call the MACRO-FUNCTION directly.
I wouldn't take that problem too seriously, for two reasons. First,
the CLtL writeup on MACRO-FUNCTION says you should call MACROEXPAND
rather than calling the function directly. Second, if you think about
where the second argument to the function comes from, it's unlikely
that (funcall (macro-function ...) ...) could be used anywhere but
inside a macro expander, where the special variables are bound,
especially if MACRO-ENVIRONMENT-EXTENT:DYNAMIC passes, except when
the environment is explicitly null, in which case there cannot be
any COMPILER-LET anyway.
Kent mentioned a similar implementation technique in his first
iteration on proposal REPAIR (in which it was the responsibility of
the compiler or interpreter to bind the variables before calling
MACROEXPAND-1). I removed it partly because it would be even easier
to subvert than the earlier REDEFINE proposal, and partly because it
looked like we were going to get bogged down in a discussion of
side-effecting the variables.
I hadn't thought of side-effecting the variables. It's important for
the language specification to say something about that. I can't justify
forbidding it (the only reason for forbidding it I can think of is
efficiency, and that's minor here), so I think it should be explicitly
allowed. This means that places that PROGV will have to copy the values
back. Alternatively it could be explicitly forbidden; I'd rather see
that than see nothing. I believe I have seen some programs that used
COMPILER-LET to bind a variable in which subsidiary macros collected
information, so side-effects are used, however those programs may have
been unportable anyway.
Note that this issue of side-effecting the variables is completely
orthogonal to everything else. It's not tied up with this question
of implementation technique.
∂14-Mar-89 1232 CL-Compiler-mailer **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 12:32:34 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556743; Tue 14-Mar-89 15:29:24 EST
Date: Tue, 14 Mar 89 15:29 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue PROCLAIM-ETC-IN-COMPILE-FILE (version 4)
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903140008.AA02608@defun.utah.edu>
Message-ID: <19890314202917.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO, primarily because this
allows programs to be clear about the scope of the proclamation:
whether they are making a proclamation for purposes of compile-file or
to affect the running Lisp. If you call the macro at top-level, you're
clearly doing it for compilation. If you call the function at any level,
you're clearly doing it with global scope.
In PROCLAIM-ETC-IN-COMPILE-FILE:NO there is no way to say whether a
PROCLAIM inside an (EVAL-WHEN (COMPILE...) ...) is intended to persist
after the compilation is over, which is just about the only reason
why I prefer PROCLAIM-ETC-IN-COMPILE-FILE:NEW-MACRO over :NO.
I'd like PROCLAIM-ETC-IN-COMPILE-FILE:NO better if it also proposed
to add an optional argument to PROCLAIM that expressed the intended
scope of the proclamation. I'd suggest NIL (the default) for the
global scope and the symbol COMPILE-FILE to limit it to the compilation.
Given this, users who liked DEFPROCLAIM could trivially write it
themselves.
The only thing PROCLAIM-ETC-IN-COMPILE-FILE:YES has going for it is
that it's the status quo, in a subset of implementations. I don't like it.
I agree with Barrett's comments quoted in the discussion section.
The proposal says:
As with other defining macros, it is
unspecified whether or not the compile-time side-effects of a
DEFPROCLAIM persist after the file has been compiled.
but never says this about PROCLAIM. In all three proposals,
this needs to be said about PROCLAIM. But as you can see from my
comments above, I would rather that we did not leave this unspecified.
The proposal says:
Current Practice:
The Symbolics compiler has special top-level handling for PROCLAIM,
although the details are not clear.
I'm not sure what you thought was not clear. Symbolics Genera does the
same thing that the current practice section says IIM does. In addition
(and I couldn't tell whether IIM does this too or not), the scope of the
PROCLAIM is only the compilation-unit if the PROCLAIM appears at
top-level, but is global and persists forever if the PROCLAIM appears in
an (EVAL-WHEN (COMPILE...) ...). We might change that.
∂14-Mar-89 1310 CL-Compiler-mailer issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:09:32 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556774; Tue 14-Mar-89 15:58:28 EST
Date: Tue, 14 Mar 89 15:58 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132333.AA02565@defun.utah.edu>
Message-ID: <19890314205826.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor DEFINING-MACROS-NON-TOP-LEVEL:ALLOW except for one thing.
This sentence appears in the proposal but does not appear to have
any relation to the main issue:
The order in which
non-top-level subforms of a top-level form are processed by the
compiler is explicitly left unspecified.
I can't figure out what this means and the example in the rationale
section that purports to explain this does not shed any light, since in
the example there is no change of order of evaluation. I wouldn't be
surprised if I opposed this if I did understand what it means. Can we
deal with this as a separate issue? In fact the whole point (3) of the
proposal should be moved. That issue should also discuss whether there
are any constraints on whether one top-level form is processed before
the next top-level form is read, in case the one form changes package,
changes readtable, defines a read-syntax, or defines a structure used in
#S read-syntax.
Also, when you say:
Clarify
that all defining macros which create functional objects (including
DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and the complex form of
DEFSETF, as well as DEFUN) must ensure that those functions are
defined in the lexical environment in which the defining form is
evaluated.
I strongly believe that MACROLET must be consistent with this, which
would be a change. Has that been dealt with as a separate issue? If
not, it should either be added to this issue or brought up as a
separate issue, with the interdependency noted in both writeups to
minimize the chance of an inconsistent vote.
∂14-Mar-89 1326 CL-Compiler-mailer issue COMPILE-FILE-SYMBOL-HANDLING, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:25:58 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556792; Tue 14-Mar-89 16:23:12 EST
Date: Tue, 14 Mar 89 16:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-FILE-SYMBOL-HANDLING, version 2
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132312.AA02542@defun.utah.edu>
Message-ID: <19890314212313.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor COMPILE-FILE-SYMBOL-HANDLING:CURRENT-PACKAGE.
COMPILE-FILE-SYMBOL-HANDLING:HOME-PACKAGE seems superficially simpler,
but my experience when we tried it at MIT indicates that it does not
work very well. Too often a symbol that had been moved from one package
to another, or had its export status changed, would be silently moved
back to its original package by loading a file. I sort-of agree with
JonL's comment at the end of the discussion section: if we can't agree
on one solution to his issue, I think that in practice there would be
little harm to portable programs if we left it unspecified. The issue
really affects development environments much more than it affects the
language in which portable programs are written, although it does have
some effect on that as well.
∂14-Mar-89 1340 CL-Compiler-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:40:33 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 556802; 14 Mar 89 16:37:50 EST
Date: Tue, 14 Mar 89 16:37 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903132250.AA02499@defun.utah.edu>
Message-ID: <19890314213750.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
All the things I didn't like in version 3 have been fixed.
I would favor COMPILE-ENVIRONMENT-CONSISTENCY:CLARIFY if one change
were made. The proposal says:
Except where some other behavior is explicitly stated, when
the compiletime and runtime definitions are different, it is
unspecified which will prevail within the compiled code.
This means that either the compiletime or the runtime definition
will prevail, but nothing else can happen. It must also be
permissible to signal an error complaining about the discrepancy.
∂14-Mar-89 1351 CL-Compiler-mailer issue SAFE-CODE, version 1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:51:31 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556829; Tue 14-Mar-89 16:49:05 EST
Date: Tue, 14 Mar 89 16:49 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue SAFE-CODE, version 1
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131726.AA02193@defun.utah.edu>
Message-ID: <19890314214907.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I agree with SAFE-CODE:SAFETY-3.
I disagree with the usage (in the examples) of "unsafe code" to mean
"all code where the OPTIMIZE quality of SAFETY is not 3." I believe
that "unsafe code" should mean code that is actually unsafe, not code
that an implementation is permitted to treat as unsafe if it wishes. I
believe there should be no portable way to write unsafe code. This is
only a matter of wording. If we need a shorter term for "all code where
the OPTIMIZE quality of SAFETY is not 3" I would suggest "potentially
unsafe code."
∂14-Mar-89 1357 CL-Compiler-mailer issue COMPILER-VERBOSITY, version 6
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 13:56:56 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556842; Tue 14-Mar-89 16:54:22 EST
Date: Tue, 14 Mar 89 16:54 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-VERBOSITY, version 6
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131546.AA02078@defun.utah.edu>
Message-ID: <19890314215423.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I like COMPILER-VERBOSITY:LIKE-LOAD. This fixes all of the
problems I had with the version 5 proposal.
Like BarMar, I question the need for either of :PRINT and :VERBOSE in
either of LOAD and COMPILE-FILE. But that might be my own cultural
bias, due to the type of systems I use, where it's easy to see what's
going on inside. If other people claim they need these, I'll believe
them.
∂14-Mar-89 1414 CL-Compiler-mailer Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Mar 89 14:14:00 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA15894; Tue, 14 Mar 89 15:11:44 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA03724; Tue, 14 Mar 89 15:11:21 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903142211.AA03724@defun.utah.edu>
Date: Tue, 14 Mar 89 15:11:20 MST
Subject: Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 14 Mar 89 15:58 EST
> Date: Tue, 14 Mar 89 15:58 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> The order in which
> non-top-level subforms of a top-level form are processed by the
> compiler is explicitly left unspecified.
>
> I can't figure out what this means and the example in the rationale
> section that purports to explain this does not shed any light, since in
> the example there is no change of order of evaluation.
I don't know how to explain this any more clearly -- what's in the
current version of the proposal is about the third attempt I've made.
Well, here goes a fourth attempt.
Suppose I have a top-level DEFMACRO at the top of the file. Item (3)
guarantees that this DEFMACRO will be processed before any top-level
forms that appear textually after it. That means I can refer to the
DEFMACRO in those subsequent forms and guarantee that the compiler has
already "seen" the macro definition. The same rule applies to any
other defining macros that do compile-time magic at top-level.
Now suppose expanding this macro has some side-effects, such as
SETQ'ing a special variable. If I have two calls to the macro at
top-level, I can reliably depend on the side-effects happening in the
same order that the calls appear textually. But, the other thing that
item (3) says is that if the two macro calls are embedded at
non-top-level, I can't rely on the order in which the compiler will
expand them.
The example shown in the rationale explains why. Both code fragments
are semantically identical -- as you observe, there is no change in
the order of evaluation. However, the *textual* order of subforms has
changed. If we wanted to guarantee that compiler processing of
*always* happens in the same order that they appear textually,
implementations would be prohibited from doing this kind of
transformation. That's why item (3) makes an exception for embedded
non-top-level forms.
I agree this could be made into a separate issue and be expanded to
include a statement that processing of top-level forms is interleaved
with reading. It had more to do with this issue when the definition
of top-level appeared here.
> Clarify
> that all defining macros which create functional objects (including
> DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and the complex form of
> DEFSETF, as well as DEFUN) must ensure that those functions are
> defined in the lexical environment in which the defining form is
> evaluated.
>
> I strongly believe that MACROLET must be consistent with this, which
> would be a change. Has that been dealt with as a separate issue? If
> not, it should either be added to this issue or brought up as a
> separate issue, with the interdependency noted in both writeups to
> minimize the chance of an inconsistent vote.
The problem with MACROLET is that it defines the macro functions at
compile time even if it appears at non-top-level, while all the other
ones listed only do so at top-level. Non-top-level environments are
not guaranteed to be "complete" at compile time; bindings of functions
and variables don't exist yet. I suppose we could say that trying to
refer to those functions and variables in the macro functions is an
error of some variety.
In any case, this would be a somewhat more incompatible change than
what the proposal currently says. Lucid, for example, evaluates
DEFMACRO macro functions in the lexical environment that the DEFMACRO
appears (in spite of what CLtL says), but always evaluates MACROLET
macro functions in a null lexical environment.
-Sandra
-------
∂14-Mar-89 1432 CL-Compiler-mailer Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Mar 89 14:32:15 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA16583; Tue, 14 Mar 89 15:29:56 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA03751; Tue, 14 Mar 89 15:29:51 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903142229.AA03751@defun.utah.edu>
Date: Tue, 14 Mar 89 15:29:49 MST
Subject: Re: issue COMPILE-FILE-SYMBOL-HANDLING, version 2
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 14 Mar 89 16:23 EST
We've gotten two contrary reports from implementors who have tried it
both ways and come up with different conclusions (you and the TI
people), and a third (Leigh Stoller here at Utah) who's switched from
HOME-PACKAGE to CURRENT-PACKAGE and who now wants to switch back to
HOME-PACKAGE because it's less complicated. The only conclusion I can
draw is that neither behavior has any great advantages over the other
in practice.
I believe we really do need to say something about how the loader
reconstructs symbols so that it is at least clear that the symbol name
and its package are the only "components" involved in the process (and
that things like the property list are not preserved). I suppose we
could come up with a much wimpier UNSPECIFIED proposal that says that
if *any* changes at all to the package hierarchy (*package*, which
symbols are imported or exported from a package, its use list, etc.)
are made between compile and load time, it's unspecified where the
loader will put the symbols.
-Sandra
-------
∂14-Mar-89 1438 CL-Compiler-mailer issue COMPILER-DIAGNOSTICS, version 9
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 14:38:21 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 556909; Tue 14-Mar-89 17:35:56 EST
Date: Tue, 14 Mar 89 17:35 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-DIAGNOSTICS, version 9
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131545.AA02075@defun.utah.edu>
Message-ID: <19890314223550.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor COMPILER-DIAGNOSTICS:USE-HANDLER, but there are two
things that I think need to be changed:
Conditions of type WARNING may be signalled by the compiler in
situations where ... the compiler can determine
that a situation that "is an error" would result at runtime.
We don't use the term "is an error" any more, do we? In the old
CLtL terms, I think both "is an error" and "signals an error"
situations would justify a warning. I think this part should
be updated to the new error terminology and also should state that
all error situations justify warnings. Of course explicit calls
to the function ERROR don't justify warnings; I don't know whether
the proposal can be phrased in such a way as to make that clear,
or whether it will have to be left to common sense.
(3) Require COMPILE and COMPILE-FILE to handle the ABORT restart by
aborting the smallest feasible part of the compilation.
I think this is wrong. The only documentation of the ABORT restart
that I could find says
The purpose of the ABORT restart is generally to allow return to the
innermost ``command level.''
I agree with this, and I believe it means that it is wrong for any
function other than one that establishes a read-eval-print loop or
a command-level to establish an ABORT restart. It would be useful
to have some restart that aborts a portion of the compilation, but
it should be given some other name.
∂14-Mar-89 1448 CL-Compiler-mailer Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Mar 89 14:48:18 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA16862; Tue, 14 Mar 89 15:46:09 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA03773; Tue, 14 Mar 89 15:46:01 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903142246.AA03773@defun.utah.edu>
Date: Tue, 14 Mar 89 15:46:00 MST
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 14 Mar 89 16:37 EST
> Date: Tue, 14 Mar 89 16:37 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> This means that either the compiletime or the runtime definition
> will prevail, but nothing else can happen. It must also be
> permissible to signal an error complaining about the discrepancy.
The very first version of this proposal said "it is an error" here,
back before we had started talking seriously about adopting new error
terminology. There was some discussion about it after that, the
consensus of which seemed to be that the right behavior should really
be "one or the other".
I personally don't see anything wrong with allowing (but not
requiring) an error to be signalled, now that we seem to have agreed
that isn't inconsistent with the term "unspecified".
-Sandra
-------
∂14-Mar-89 1508 CL-Compiler-mailer Re: issue COMPILER-DIAGNOSTICS, version 9
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Mar 89 15:08:20 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA17542; Tue, 14 Mar 89 16:05:33 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA03799; Tue, 14 Mar 89 16:05:31 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903142305.AA03799@defun.utah.edu>
Date: Tue, 14 Mar 89 16:05:30 MST
Subject: Re: issue COMPILER-DIAGNOSTICS, version 9
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: kmp@stony-brook.scrc.symbolics.com, cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 14 Mar 89 17:35 EST
> Date: Tue, 14 Mar 89 17:35 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> We don't use the term "is an error" any more, do we? In the old
> CLtL terms, I think both "is an error" and "signals an error"
> situations would justify a warning. I think this part should
> be updated to the new error terminology and also should state that
> all error situations justify warnings. Of course explicit calls
> to the function ERROR don't justify warnings; I don't know whether
> the proposal can be phrased in such a way as to make that clear,
> or whether it will have to be left to common sense.
I had similar thoughts as I was looking this over before sending it
out, but I couldn't think of a way to state this that would make
sense. I felt sure that if I just changed "is an error" to "is
undefined or where an error would be signalled", somebody would be
sure to complain about it being wrong for explicit calls to ERROR.
Actually, I was hoping that if I left it alone, somebody else would
propose some alternate wording. :-)
> (3) Require COMPILE and COMPILE-FILE to handle the ABORT restart by
> aborting the smallest feasible part of the compilation.
>
> I think this is wrong.
This was originally a suggestion from Kent Pitman, who probably knows
better than anybody what the ABORT restart was intended to be used
for. You'll have to take it up with him, because I don't feel
qualified to argue about it one way or the other.
-Sandra
-------
∂14-Mar-89 1544 CL-Compiler-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from YUKON.SCRC.Symbolics.COM (SCRC-YUKON.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 15:44:06 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by YUKON.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 438041; Tue 14-Mar-89 18:42:58 EST
Date: Tue, 14 Mar 89 18:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903140019.AA02631@defun.utah.edu>
Message-ID: <19890314234118.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
This looks good so far. A few comments that might help you
along with the draft:
VARIABLE-KIND should return the same second value that FUNCTION-KIND
returns.
It's a good idea to avoid the ambiguous word "may" and say "might",
"must", or "is permitted to".
I would assume that VARIABLE-TYPE is not required to return the
exact declared type specifier, but could return another type
specifier that is equivalent, or possibly another type specifier
that is a supertype. An implementation that canonicalizes type
declarations would do this. For example, if A was declared
(INTEGER 0 4999), VARIABLE-TYPE might return that list, another
list that was EQUAL to it but not EQ, the list (INTEGER (-1) (5000)),
the symbol FIXNUM, or perhaps something else. Similarly OR's and
AND's might be reduced to simpler type specifiers in an implementation
dependent way. If, on the other hand, VARIABLE-TYPE is not permitted
to do this, but must return the exact type specifier used in the
declaration, that would be okay, but should be stated explicitly.
Similar comments apply to FUNCTION-FTYPE of course.
I assume AUGMENT-ENVIRONMENT is permitted to share structure with
its env argument, although the proposal says "a copy of ENV".
The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
of a MACROLET special form, instead it should be a list of lists (name
function). That is, the expander functions should be supplied in the
form of functions rather than in the form of the source text used by
MACROLET. Your rationale argues against this but I strongly believe
that the rationale is wrong. I wouldn't mind seeing the parsing portion
of MACROLET made available as a separate function.
No way is provided to retrieve declarations other than SPECIAL, TYPE,
FTYPE, and LEXICAL (if PROCLAIM-LEXICAL passes). I think all
declarations should be retrievable, but OPTIMIZE declarations seem
particularly useful to retrieve in macros or optimizers that expand into
different code depending on the safety level or the speed/space
tradeoff. The irregular structure of declarations makes retrieving
them a bit complex, but here's my suggestion:
DECLARATION decl-type name &optional env [Function]
decl-type is a symbol. The interpretation of name depends
on decl-type. If a declaration of that type and name is
in force in the specified environment, it is returned, otherwise
NIL is returned. The following decl-types are specified,
additional implementation-dependent types could be added:
INLINE function-name => T or NIL
NOTINLINE function-name => T or NIL
IGNORE variable-name => T or NIL
OPTIMIZE quality => integer
DECLARATION decl-type => T or NIL
The possible interpreter implementation of COMPILER-LET I mentioned
in another message earlier today would seem to require another
keyword argument to AUGMENT-ENVIRONMENT. Does this mean that we
have to dictate some particular interpreter implementation of
COMPILER-LET? I'm unsure.
Symbolics Genera includes an undocumented internal macro, used
quite a bit in the implementation of the interpreter and code
analyzers, that could have been called WITH-AUGMENTED-ENVIRONMENT,
taking keywords like AUGMENT-ENVIRONMENT and also body forms,
and producing an environment with dynamic extent bound to a
variable within the body forms. Would it be useful to have this
too, or instead of AUGMENT-ENVIRONMENT? I'm unsure.
On SYNTACTIC-ENVIRONMENT-ACCESS:MEDIUM, my feeling today is that
this should be left out for now, even though I think we will want
something like it later, at the same time that CLOS metaobjects
go in.
Ditto for SYNTACTIC-ENVIRONMENT-ACCESS:LARGE.
∂14-Mar-89 1629 CL-Compiler-mailer issue CONSTANT-COMPILABLE-TYPES, version 8
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 16:29:32 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557038; Tue 14-Mar-89 19:27:03 EST
Date: Tue, 14 Mar 89 19:27 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CONSTANT-COMPILABLE-TYPES, version 8
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131612.AA02083@defun.utah.edu>
Message-ID: <19890315002703.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
I apologize in advance for the length of this message.
This is good except for a few typos and the controversial business about
functions. I'd really like to see another round of editing to clean up
these problems before we're asked to vote on this.
I suggest moving everything having to do with functions to a
separate proposal. What's currently in the body of the proposal for
functions does not make any sense to me. I basically agree with the
comments from both Loosemore and Gabriel about this quoted in the
discussion section. However, we need to be careful when we discuss this
to distinguish between a function as a constant in compiled code, and a
form whose result is a function appearing in compiled code. The former
is `(quote ,#'(lambda ...)), the latter is `#'(lambda ...). The meaning
of the latter is clear, of course, and a useful question would be
whether it can fully satisfy the need for functions in compiled code and
eliminate any demand for the former.
I've said this before, but I still think the proposal would be
easier to understand if it explicitly dealt separately with
(1) relation of objects in the input of COMPILE-FILE to corresponding
objects in the result of LOAD of the output of COMPILE-FILE.
(2) relation of two objects in the output of a single COMPILE-FILE.
(3) relation of two objects in the output of two different COMPILE-FILEs.
instead of smushing these together in a fuzzy way. Look at the discussion
of uninterned symbols, for example: I found it incomprehensible.
Typos:
For any object that
appears in a constant, but is not supported by the language as part of
a constant, the behavior of the compiler is unspecified; either the
the compiler and/or loader will handle that constant (in an
implementation-dependent manner) or the compiler will detect the
situation and signal an error.
This says that the behavior of the compiler is unspecified and then
proceeds to specify it!
Because hash keys can be aggregate objects and because we treat hash
tables as unordered sets of <key, value> pairs, similarity of hash
tables is more complex. See under "Hash Tables", below, for the
definition.
I have no idea how this paragraph got into the middle of the discussion
of uninterned symbols.
References to packages are permitted in any constant.
This sentence is redundant, or else it implies that references to some
other types are permitted in some constants but not in other constants,
which I don't think you intended.
At load time, the package becomes the same as returned by
I don't know what it means for a package to "become". I think
this is just fractured syntax, though. See again my suggestion
for distinguishing the three types of similarity, which I think
indicates how to rewrite this sentence to be clear.
Under hash table:
The table's test is unchanged also.
Unchanged from what? I think what this was supposed to say was
that the table's test is a "basic attribute."
Consider a hash table as an unordered set of key and
value pairs. Two hash tables are similar as constants
exactly if there is a one-to-one correspondence between
the key and value pairs of each and a one-to-one
correspondence between the uninterned symbols of each
such that the two keys of each corresponding pair are
similar as constants and the two values are also similar
as constants. The correspondence of uninterned symbols
must be consistent with the correspondence defined for
the entire set of constants in the file.
This paragraph is totally garbled. If you took out the
stuff about uninterned symbols it might make sense.
Structure, Standard-object
<<There is a cl-cleanup issue, LOAD-OBJECTS, pending
which proposes a mechanism for dealing with objects.>>
For structure instances with no method defined at compile
time for MAKE-LOAD-FORM, the slot values and the name of
structure type (a symbol reference) are recorded by the
compiler and reconstructed by the loader.
The text not enclosed in french quotation marks directly contradicts
the LOAD-OBJECTS proposal. It should be removed so we don't have two
proposals trying to talk about the same thing.
This sentence in the discussion section:
The full extension of the concept of coalescing of constants is to say
that they can be coalesced exactly when they are similar as constants.
seems to be in the wrong document, since this issue is not about
coalescing of constants and does not otherwise mention it, except
incidentally in connection with a bug in Coral Lisp.
∂14-Mar-89 1636 CL-Compiler-mailer issue CONSTANT-COMPILABLE-TYPES, version 8
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 16:36:44 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557048; Tue 14-Mar-89 19:34:07 EST
Date: Tue, 14 Mar 89 19:34 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CONSTANT-COMPILABLE-TYPES, version 8
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131612.AA02083@defun.utah.edu>
Supersedes: <19890315002703.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Comments: Fix some typos in the definitions of the three concepts that I claim
should not be smushed together. Cris Perdue pointed out these typos
earlier, but I forgot to fix them before sending the first copy of this
message.
Message-ID: <19890315003408.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
I apologize in advance for the length of this message.
This is good except for a few typos and the controversial business about
functions. I'd really like to see another round of editing to clean up
these problems before we're asked to vote on this.
I suggest moving everything having to do with functions to a
separate proposal. What's currently in the body of the proposal for
functions does not make any sense to me. I basically agree with the
comments from both Loosemore and Gabriel about this quoted in the
discussion section. However, we need to be careful when we discuss this
to distinguish between a function as a constant in compiled code, and a
form whose result is a function appearing in compiled code. The former
is `(quote ,#'(lambda ...)), the latter is `#'(lambda ...). The meaning
of the latter is clear, of course, and a useful question would be
whether it can fully satisfy the need for functions in compiled code and
eliminate any demand for the former.
I've said this before, but I still think the proposal would be
easier to understand if it explicitly dealt separately with
(1) relation of objects in the input of COMPILE-FILE to corresponding
objects in the result of LOAD of the output of COMPILE-FILE.
(2) relation of two objects in the result of LOAD of the output
of a single COMPILE-FILE.
(3) relation of two objects in the result of LOAD of the output
of two different COMPILE-FILEs.
instead of smushing these together in a fuzzy way. Look at the discussion
of uninterned symbols, for example: I found it incomprehensible.
Typos:
For any object that
appears in a constant, but is not supported by the language as part of
a constant, the behavior of the compiler is unspecified; either the
the compiler and/or loader will handle that constant (in an
implementation-dependent manner) or the compiler will detect the
situation and signal an error.
This says that the behavior of the compiler is unspecified and then
proceeds to specify it!
Because hash keys can be aggregate objects and because we treat hash
tables as unordered sets of <key, value> pairs, similarity of hash
tables is more complex. See under "Hash Tables", below, for the
definition.
I have no idea how this paragraph got into the middle of the discussion
of uninterned symbols.
References to packages are permitted in any constant.
This sentence is redundant, or else it implies that references to some
other types are permitted in some constants but not in other constants,
which I don't think you intended.
At load time, the package becomes the same as returned by
I don't know what it means for a package to "become". I think
this is just fractured syntax, though. See again my suggestion
for distinguishing the three types of similarity, which I think
indicates how to rewrite this sentence to be clear.
Under hash table:
The table's test is unchanged also.
Unchanged from what? I think what this was supposed to say was
that the table's test is a "basic attribute."
Consider a hash table as an unordered set of key and
value pairs. Two hash tables are similar as constants
exactly if there is a one-to-one correspondence between
the key and value pairs of each and a one-to-one
correspondence between the uninterned symbols of each
such that the two keys of each corresponding pair are
similar as constants and the two values are also similar
as constants. The correspondence of uninterned symbols
must be consistent with the correspondence defined for
the entire set of constants in the file.
This paragraph is totally garbled. If you took out the
stuff about uninterned symbols it might make sense.
Structure, Standard-object
<<There is a cl-cleanup issue, LOAD-OBJECTS, pending
which proposes a mechanism for dealing with objects.>>
For structure instances with no method defined at compile
time for MAKE-LOAD-FORM, the slot values and the name of
structure type (a symbol reference) are recorded by the
compiler and reconstructed by the loader.
The text not enclosed in french quotation marks directly contradicts
the LOAD-OBJECTS proposal. It should be removed so we don't have two
proposals trying to talk about the same thing.
This sentence in the discussion section:
The full extension of the concept of coalescing of constants is to say
that they can be coalesced exactly when they are similar as constants.
seems to be in the wrong document, since this issue is not about
coalescing of constants and does not otherwise mention it, except
incidentally in connection with a bug in Coral Lisp.
∂14-Mar-89 1651 CL-Compiler-mailer issue QUOTE-SEMANTICS, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 16:51:17 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557056; Tue 14-Mar-89 19:48:51 EST
Date: Tue, 14 Mar 89 19:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue QUOTE-SEMANTICS, version 2
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131721.AA02184@defun.utah.edu>
Message-ID: <19890315004852.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor QUOTE-SEMANTICS:NO-COPYING for two reasons:
(1) it's clearly more aesthetic.
(2) I can't support either of the other two proposals because they use
the words "copying" and "coalescing" without defining their meaning.
My position could be changed to
QUOTE-SEMANTICS:COPYING-ALLOWED-BUT-NO-CONSTRAINTS by adding definitions
for those two words and by a strong argument that the implementation
cost of QUOTE-SEMANTICS:NO-COPYING is too high, since I believe to some
extent JonL's argument (quoted in the discussion section) that EQL of
(some types of) constants does not matter.
I can't imagine any argument that would convince me to
support QUOTE-SEMANTICS:SAME-AS-COMPILE-FILE. I believe Kent's
arguments against it (quoted in the discussion section).
∂14-Mar-89 1700 CL-Compiler-mailer issue MACRO-CACHING, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:00:30 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557059; Tue 14-Mar-89 19:57:55 EST
Date: Tue, 14 Mar 89 19:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue MACRO-CACHING, version 2
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131647.AA02151@defun.utah.edu>
Message-ID: <19890315005756.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
I support MACRO-CACHING:DISALLOW. I'd like to point out that the
"correct" way to do macro caching is not mentioned anywhere in this
writeup. Perhaps that was justified because there is no portable way to
do it (an implementation can do it, but a user cannot), however I think
omitting it leaves a false impression.
The "correct" way to do macro caching is via a table inside the lexical
environment structure, which has very different properties from a table
keyed by the lexical environment structure, mentioned in the writeup.
I think a shorter writeup might be better. It could simply say that
there is no correct portable way to use *MACROEXPANSION-HOOK* to cache
macro expansions, and that there is no requirement that an implementation
call the macro expansion function more than once for a given form
and lexical environment. This prohibits the incorrect user code discussed
at some length in the existing writeup, leaves implementations license
to do macro caching correctly, and avoids a lot of unnecessary detail.
∂14-Mar-89 1704 CL-Compiler-mailer issue LOAD-TIME-EVAL, version 11
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:04:49 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 557069; 14 Mar 89 20:02:04 EST
Date: Tue, 14 Mar 89 20:02 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue LOAD-TIME-EVAL, version 11
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131631.AA02140@defun.utah.edu>
Message-ID: <19890315010205.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
I like LOAD-TIME-EVAL:R**3-NEW-SPECIAL-FORM.
∂14-Mar-89 1722 CL-Compiler-mailer issue CONSTANT-CIRCULAR-COMPILATION, version 7
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:21:59 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557096; Tue 14-Mar-89 20:15:39 EST
Date: Tue, 14 Mar 89 20:15 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CONSTANT-CIRCULAR-COMPILATION, version 7
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131619.AA02090@defun.utah.edu>
Message-ID: <19890315011539.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I favor CONSTANT-CIRCULAR-COMPILATION:YES except that all references to
EQ should be changed to EQL. There is no reason to require
implementations to be careful about EQ of numbers and characters.
∂14-Mar-89 1722 CL-Compiler-mailer issue CONSTANT-COLLAPSING, version 5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:21:52 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557083; Tue 14-Mar-89 20:10:42 EST
Date: Tue, 14 Mar 89 20:10 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue CONSTANT-COLLAPSING, version 5
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131622.AA02093@defun.utah.edu>
Message-ID: <19890315011043.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
The proposal says:
State the an implementation is permitted to coalesce constants
appearing in code to be compiled if they are equivalent under the
relationship defined in proposal CONSTANT-COMPILABLE-TYPES:SPECIFY.
I can't understand what this means. The referenced proposal uses
the word "similar", not "equivalent". I'd support this alternate
wording:
Suppose that A and B are two objects used as quoted constants in the
input to COMPILE-FILE, and that A' and B' are the corresponding
objects used as constants in the result of loading the output of
that COMPILE-FILE. If A' is similar as a constant to both A and B,
then it is valid for A' and B' to be EQL even if A and B are not EQL.
This may still be too vague, since "objects in the input to
COMPILE-FILE" means not in the input text file, which doesn't contain
objects, but in the result of applying READ to the input file, and since
"corresponding objects" is not defined.
∂14-Mar-89 1730 CL-Compiler-mailer issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:29:45 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 557112; 14 Mar 89 20:27:21 EST
Date: Tue, 14 Mar 89 20:27 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
To: cl-compiler@sail.stanford.edu
cc: x3j13@sail.stanford.edu
In-Reply-To: <8903131544.AA02070@defun.utah.edu>
Message-ID: <19890315012722.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
I much prefer the option FLUSH, which was in version 2 but has been
removed. That option was to remove the COMPILED-FUNCTION type.
This type has no portable meaning and never should have existed.
I have no objection to the proposed specification of what the COMPILE
and COMPILE-FILE functions do, but it should be decoupled from the
COMPILED-FUNCTION type and discussed under the rubric of those two
functions. The parts about COMPILER-LET and EVAL-WHEN can probably be
removed (assuming the COMPILER-LET-CONFUSION proposal that eliminates
the possibility of COMPILER-LET binding any variables at run time
passes, and the EVAL-WHEN-NON-TOP-LEVEL proposal passes) since they are
redundant; there is never any interpeter/compiler difference for
COMPILER-LET or EVAL-WHEN any more.
∂14-Mar-89 1732 CL-Compiler-mailer Re: Potential issue: MACRO-SPECIAL-FORMS
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 14 Mar 89 17:32:00 PST
Received: from Semillon.ms by ArpaGateway.ms ; 14 MAR 89 16:49:34 PST
Date: 14 Mar 89 16:48 PST
From: masinter.pa@Xerox.COM
Subject: Re: Potential issue: MACRO-SPECIAL-FORMS
In-reply-to: Gregor.pa's message of Thu, 9 Mar 89 19:14 PST
To: Gregor.pa@Xerox.COM, David A. Moon
<Moon@STONY-BROOK.SCRC.Symbolics.COM>, Jeff Dalton
<jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>, Kent M Pitman
<KMP@STONY-BROOK.SCRC.Symbolics.COM>, cl-compiler@sail.stanford.edu,
cl-cleanup@sail.stanford.edu
Message-ID: <890314-164934-2319@Xerox>
a) if anything is going to happen on this at the next meeting, we need a
proposal writeup. This week.
b) I like the proposal (in Jeff's oiginal "potential issue"). I agree that
we might want something stronger -- like extending the list of special
forms to include the ones that a code walker *really* has to know about,
but I don't know if we can reach closure.
c) I'd rather do nothing than do something wrong.
∂14-Mar-89 1810 CL-Compiler-mailer Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Mar 89 18:09:53 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA23949; Tue, 14 Mar 89 19:07:40 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA04006; Tue, 14 Mar 89 19:07:33 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903150207.AA04006@defun.utah.edu>
Date: Tue, 14 Mar 89 19:07:31 MST
Subject: Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 14 Mar 89 18:41 EST
> Date: Tue, 14 Mar 89 18:41 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> I would assume that VARIABLE-TYPE is not required to return the
> exact declared type specifier, but could return another type
> specifier that is equivalent, or possibly another type specifier
> that is a supertype.
That sounds reasonable to me.
> The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
> of a MACROLET special form, instead it should be a list of lists (name
> function). That is, the expander functions should be supplied in the
> form of functions rather than in the form of the source text used by
> MACROLET. Your rationale argues against this but I strongly believe
> that the rationale is wrong. I wouldn't mind seeing the parsing portion
> of MACROLET made available as a separate function.
Can you provide a rationale for this?
Actually, I wouldn't object to the change as long as the function to do
the parsing is provided. (I speak from personal experience, this is
really a hairy piece of code to have to write from scratch.) How about
PARSE-MACRO name-and-definition &optional env [Function]
Name-and-definition a list of the form (name lambda-list . body),
as in the format of a MACROLET special form. Two values are returned:
the name of the macro and a macro function.
> DECLARATION decl-type name &optional env [Function]
>
> decl-type is a symbol. The interpretation of name depends
> on decl-type. If a declaration of that type and name is
> in force in the specified environment, it is returned, otherwise
> NIL is returned. The following decl-types are specified,
> additional implementation-dependent types could be added:
>
> INLINE function-name => T or NIL
> NOTINLINE function-name => T or NIL
> IGNORE variable-name => T or NIL
> OPTIMIZE quality => integer
> DECLARATION decl-type => T or NIL
Hmmm. Could we extend this to handle the TYPE and FTYPE declarations
too, and dispense with VARIABLE-TYPE and FUNCTION-FTYPE? And, should
the symbols for the decl-type argument be keywords?
> The possible interpreter implementation of COMPILER-LET I mentioned
> in another message earlier today would seem to require another
> keyword argument to AUGMENT-ENVIRONMENT. Does this mean that we
> have to dictate some particular interpreter implementation of
> COMPILER-LET? I'm unsure.
I believe so. It wouldn't work for a user codewalker to bind
COMPILER-LET variables specially before walking the body, if
MACROEXPAND-1 is going to look in the environment for variables to
bind. (It may mistakenly bind a variable in an outer contour that is
supposed to be shadowed by one the codewalker bound.) And it wouldn't
work for code walkers just to add the bindings to the environment if
MACROEXPAND-1 doesn't look for them.
Do you really want to go ahead with this idea? At the very least, I
think it would have to be presented as a separate proposal from
COMPILER-LET-CONFUSION:REPAIR, instead of just suggested as a way to
implement that proposal.
-Sandra
-------
∂14-Mar-89 1922 CL-Compiler-mailer comments on issues
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 14 Mar 89 19:22:43 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA25232; Tue, 14 Mar 89 20:20:34 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA04102; Tue, 14 Mar 89 20:20:32 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903150320.AA04102@defun.utah.edu>
Date: Tue, 14 Mar 89 20:20:30 MST
Subject: comments on issues
To: cl-compiler@sail.stanford.edu
Dave Moon has given us some excellent comments on our pending issues.
At this point, it seems like most of the writeups are going to need
one more round of tweaks before the meeting. I propose to start doing
the revisions around the middle of next week. So, if any of you have
anything more to say, please do so by next Tuesday (the 21st).
In other news, I've heard from Jan that the agenda for the meeting has
been reshuffled, and we are now scheduled to go on Thursday morning
right after the editorial committee report.
-Sandra
-------
∂15-Mar-89 0508 CL-Compiler-mailer Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 05:07:47 PST
Received: from Semillon.ms by ArpaGateway.ms ; 15 MAR 89 05:00:44 PST
Date: 15 Mar 89 05:00 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
Mon, 13 Mar 89 15:50:07 -0700
To: cl-compiler@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890315-050044-3449@Xerox>
I think I know what this means, but I worry that the language isn't precise
enough and we will have some problems with misreading. This leaves it an
"editorial" issue, I suppose, but I don't envy the job of the editor. Just
some examples:
(b) In conforming code, variables that are intended to be bound
specially must be declared SPECIAL in the compiletime environment
before any bindings of that variable are processed by the compiler.
The compiler must treat any binding of an undeclared variable as a
lexical binding.
The terms I'd wish defined are
"intended" - by whom?
"declared... in the compiletime environment before"
- probably you mean that the compiler must process an appropriate
DECLARE or PROCLAIM, not that such a DECLARE or PROCLAIM actually
be evaluated. Probably "before" means either chronologically or
in some appropriate lexically enclosing scope.
"processed by the compiler"
- probably "processed" doesn't include READ.
d
∂15-Mar-89 0636 CL-Compiler-mailer Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Mar 89 06:36:09 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA06665; Wed, 15 Mar 89 07:33:53 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA04537; Wed, 15 Mar 89 07:33:49 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903151433.AA04537@defun.utah.edu>
Date: Wed, 15 Mar 89 07:33:47 MST
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
To: masinter.pa@Xerox.COM
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM, 15 Mar 89 05:00 PST
Sigh. I've already gone over the wording on this issue once with
Kathy Chapman and incorporated her suggestions. If you have some
specific alternate wording you would like to see, please let me know.
I don't have any particularly strong attachment to the current
language.
-Sandra
-------
∂15-Mar-89 0913 CL-Compiler-mailer Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 09:13:18 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557474; Wed 15-Mar-89 12:10:25 EST
Date: Wed, 15 Mar 89 12:10 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@sail.stanford.edu
In-Reply-To: <8903150207.AA04006@defun.utah.edu>
Message-ID: <19890315171024.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 14 Mar 89 19:07:31 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Date: Tue, 14 Mar 89 18:41 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
> of a MACROLET special form, instead it should be a list of lists (name
> function). That is, the expander functions should be supplied in the
> form of functions rather than in the form of the source text used by
> MACROLET. Your rationale argues against this but I strongly believe
> that the rationale is wrong. I wouldn't mind seeing the parsing portion
> of MACROLET made available as a separate function.
Can you provide a rationale for this?
What if we got here not via looking at a MACROLET in the user's source,
but through some other path that causes us to want to use local macros?
Should we have to take the expander functions in our hand and somehow
turn them back into MACROLET syntax so AUGMENT-ENVIRONMENT can turn them
back into functions again? It's a simple question of levels of abstraction.
Actually, I wouldn't object to the change as long as the function to do
the parsing is provided. (I speak from personal experience, this is
really a hairy piece of code to have to write from scratch.)
Not if you have DESTRUCTURING-BIND. But I guess that hasn't been
accepted into the language yet.
How about
PARSE-MACRO name-and-definition &optional env [Function]
Name-and-definition a list of the form (name lambda-list . body),
as in the format of a MACROLET special form. Two values are returned:
the name of the macro and a macro function.
It should return a lambda expression, not a function. Most likely that
is what you really meant to say. I have a mild preference for passing
the name, lambda-list, and body as separate arguments, and returning
only the function, not the name, but that's not vital. But I would propose:
PARSE-MACRO name lambda-list body &optional env [Function]
Processes the lambda-list in the same way that DEFMACRO and MACROLET do.
Returns a lambda-expression that accepts two arguments (form and env)
and returns the macro expansion. Name is the name of the macro and
is supplied as an argument for implementation-dependent use, such as
including the name of the macro in error messages issued if the form
does not match the lambda-list.
> DECLARATION decl-type name &optional env [Function]
>
> decl-type is a symbol. The interpretation of name depends
> on decl-type. If a declaration of that type and name is
> in force in the specified environment, it is returned, otherwise
> NIL is returned. The following decl-types are specified,
> additional implementation-dependent types could be added:
>
> INLINE function-name => T or NIL
> NOTINLINE function-name => T or NIL
> IGNORE variable-name => T or NIL
> OPTIMIZE quality => integer
> DECLARATION decl-type => T or NIL
Hmmm. Could we extend this to handle the TYPE and FTYPE declarations
too, and dispense with VARIABLE-TYPE and FUNCTION-FTYPE?
The problem is that the declaration scoping rules require that both
declarations and bindings be examined in parallel to decide whether a
declaration is in force or is shadowed by a binding inside it. This
applies to TYPE, FTYPE, INLINE, NOTINLINE, SPECIAL, and IGNORE. I
thought about this for quite some time. The choice is whether to have
one DECLARATION function that behaves irregularly, using different
scoping rules for different decl-type arguments, or to have separate
functions VARIABLE-TYPE, FUNCTION-FTYPE, FUNCTION-INLINE, VARIABLE-KIND,
and VARIABLE-IGNORED. FUNCTION-INLINE would return one of NIL, INLINE,
or NOTINLINE.
I hadn't realized the full scope of this problem when I sent my comments
yesterday. I haven't yet settled on a position that I believe, however
I don't like the proposal as it stands because it offers access to some
declarations but not to others. I remember an older version of the
proposal had one function for variables and one for functions, and each
returned multiple values which were the complete information about the
variable or function. What was the criterion for getting rid of that?
It might help decide this issue too. Can we continue discussing this?
And, should the symbols for the decl-type argument be keywords?
Absolutely not! They should be the same symbols that DECLARE uses.
> The possible interpreter implementation of COMPILER-LET I mentioned
> in another message earlier today would seem to require another
> keyword argument to AUGMENT-ENVIRONMENT. Does this mean that we
> have to dictate some particular interpreter implementation of
> COMPILER-LET? I'm unsure.
I believe so. It wouldn't work for a user codewalker to bind
COMPILER-LET variables specially before walking the body, if
MACROEXPAND-1 is going to look in the environment for variables to
bind. (It may mistakenly bind a variable in an outer contour that is
supposed to be shadowed by one the codewalker bound.) And it wouldn't
work for code walkers just to add the bindings to the environment if
MACROEXPAND-1 doesn't look for them.
Do you really want to go ahead with this idea? At the very least, I
think it would have to be presented as a separate proposal from
COMPILER-LET-CONFUSION:REPAIR, instead of just suggested as a way to
implement that proposal.
I still believe that this way of doing COMPILER-LET is better than
fully expanding all macros whenever the interpreter sees a COMPILER-LET.
But I don't feel very confident in dictating a particular implementation.
Can we continue discussing this?
∂15-Mar-89 1043 CL-Compiler-mailer Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Mar 89 10:42:58 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA15806; Wed, 15 Mar 89 11:40:39 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA04690; Wed, 15 Mar 89 11:40:36 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903151840.AA04690@defun.utah.edu>
Date: Wed, 15 Mar 89 11:40:35 MST
Subject: Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
cl-compiler@sail.stanford.edu
> Date: Wed, 15 Mar 89 12:10 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> Not if you have DESTRUCTURING-BIND. But I guess that hasn't been
> accepted into the language yet.
Is there a cleanup proposal afoot to add this? I don't remember seeing
this on the list Larry distributed at the last meeting.
> PARSE-MACRO name lambda-list body &optional env [Function]
>
> Processes the lambda-list in the same way that DEFMACRO and MACROLET do.
> Returns a lambda-expression that accepts two arguments (form and env)
> and returns the macro expansion.
If this function doesn't actually do any evaluation to construct a
real function, is it really necessary to have it accept an environment
argument?
Also, a long time ago we passed a cleanup issue saying that the body
of a macro definition established with MACROLET or DEFMACRO has an
implicit BLOCK around it. Unless you want the "body" argument to
already include the BLOCK, you need the "name" argument for this
purpose. Let's be explicit about it, one way or the other.
> I don't like the proposal as it stands because it offers access to some
> declarations but not to others. I remember an older version of the
> proposal had one function for variables and one for functions, and each
> returned multiple values which were the complete information about the
> variable or function. What was the criterion for getting rid of that?
Looking over back mail on this issue, I see that you made a similar
suggestion while we were discussing version 1, but that it was never
incorporated into any later version of the writeup. It would help me
to understand the issues involved better if you can come up with
something specific on this.
Incidentally, version 1 did include individual accessor functions for
INLINE and OPTIMIZE declarations, plus hooks for dealing with block
names and go tags that are not included in later versions.
> Can we continue discussing this?
Yes, but let's discuss the problems with COMPILER-LET separately.
Neither of the existing COMPILER-LET proposals require anything
special to be done with the environment accessor issue.
-Sandra
-------
∂15-Mar-89 0800 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Mar 89 08:00:32 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA09473; Wed, 15 Mar 89 08:58:15 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA04583; Wed, 15 Mar 89 08:58:10 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903151558.AA04583@defun.utah.edu>
Date: Wed, 15 Mar 89 08:58:09 MST
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 14 Mar 89 20:27 EST
> I have no objection to the proposed specification of what the COMPILE
> and COMPILE-FILE functions do, but it should be decoupled from the
> COMPILED-FUNCTION type and discussed under the rubric of those two
> functions.
I was envisioning that this material would end up in section 4.2 of
the standard, in the subsection that presents our simple model of what
a compiler does. If proposal TIGHTEN passes, the definition of the
COMPILED-FUNCTION type in section 2.2 would contain a reference to it.
I don't have any any objection to restoring the FLUSH proposal.
-Sandra
-------
∂15-Mar-89 1345 CL-Compiler-mailer issue COMPILER-LET-CONFUSION, version 7
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Mar 89 13:45:23 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA25671; Wed, 15 Mar 89 14:43:11 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA04763; Wed, 15 Mar 89 14:42:55 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903152142.AA04763@defun.utah.edu>
Date: Wed, 15 Mar 89 14:42:54 MST
Subject: issue COMPILER-LET-CONFUSION, version 7
To: moon@stony-brook.scrc.symbolics.com
Cc: cl-compiler@sail.stanford.edu
If you really want to pursue the idea of storing COMPILER-LET bindings
in the environment, perhaps we should try to revive another idea that
was suggested by Pitman some time ago in this connection:
> Suppose that instead of referencing the value as a special, you had
> an operator COMPILER-SYMBOL-VALUE to get its value. [That could be a
> function, macro, or special form.] I wouldn't have a problem calling
> a function to get this data because I still get to use the same basic
> `shape' of code. Also, uses of COMPILER-LET are rare enough that a
> bit of extra syntax is not overwhelming.
>
> (DEFMACRO mac (...)
> ... (COMPILER-SYMBOL-VALUE name) ...)
>
> (new-COMPILER-LET ((name val))
> ...)
>
> I don't know how other supporters of COMPILER-LET would feel about this.
> It looks ok to me, though.
>
> I can't think of any implementations in which this would be prohibitively
> expensive to implement.
COMPILER-SYMBOL-VALUE would also have to take an optional environment
argument, of course.
As I've pointed out before, it's possible to implement something like
this already by using SYMBOL-MACROLET as a primitive, provided that
you're willing to do without SETF'ing the "variables". Kent has
complained that he doesn't like the idea of having the symbol macros
shadow the normal (lexical or special) bindings of the variable that
would be visible at runtime, though. (Personally, I believe anybody
who uses the same variables in a COMPILER-LET that are also used at
runtime in the same lexical scope is asking for trouble anyway.)
If the shadowing problem could be sorted out, I wouldn't object to
seeing this firmed up into a real proposal to redefine COMPILER-LET to
work this way. You'd also have to add a keyword argument to
AUGMENT-ENVIRONMENT, and something so you can tell whether a variable
has a COMPILER-LET "binding" or not.
-Sandra
-------
∂15-Mar-89 1408 CL-Compiler-mailer issue COMPILER-LET-CONFUSION, version 7
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 15 Mar 89 14:08:41 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 557884; Wed 15-Mar-89 17:05:12 EST
Date: Wed, 15 Mar 89 17:05 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILER-LET-CONFUSION, version 7
To: sandra%defun@cs.utah.edu
cc: moon@STONY-BROOK.SCRC.Symbolics.COM, cl-compiler@sail.stanford.edu
In-Reply-To: <8903152142.AA04763@defun.utah.edu>
Message-ID: <890315170502.7.KMP@BOBOLINK.SCRC.Symbolics.COM>
People have suggested that if it comes to making an incompatible change
on this one, it's probably better to just remove the feature and let
people continue to provide it compatibly where they think it's useful.
Even though I think the COMPILER-SYMBOL-VALUE thing is technically
doable, I find myself swayed by arguments that it's not the correct
avenue for us to pursue at this time.
∂15-Mar-89 1451 CL-Compiler-mailer Issue SAFE-CODE, version 1
To: cl-compiler@SAIL.Stanford.EDU, x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
According to my understanding of the dictionary definitions,
``unsafe'' means primarily ``the opposite or reversal of `safe' '' and
secondarily ``not safe.'' This coincides with Moon's reading.
Therefore, I propose we use the term ``nonsafe'' which clearly means
``not safe.'' This, coupled with the already very explicit definition
of ``unsafe,'' which explains that unsafe code might actually be safe,
should take care of his objection.
-rpg-
∂15-Mar-89 1449 CL-Compiler-mailer Re: issue COMPILER-LET-CONFUSION, version 7
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Mar 89 14:49:24 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA28484; Wed, 15 Mar 89 15:42:54 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA04812; Wed, 15 Mar 89 15:41:55 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903152241.AA04812@defun.utah.edu>
Date: Wed, 15 Mar 89 15:41:53 MST
Subject: Re: issue COMPILER-LET-CONFUSION, version 7
To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Cc: moon@STONY-BROOK.SCRC.Symbolics.COM, cl-compiler@sail.stanford.edu
In-Reply-To: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 15 Mar 89 17:05 EST
I tend to agree -- proposal REPAIR is about the most we can do to
clean up COMPILER-LET without assigning it radically different
semantics from what's specified in CLtL. While I don't want to
squelch further discussion on this issue if people really are
discontented with both of the existing proposals, I'm not going to
take the initiative to put together any additional proposals myself.
-Sandra
-------
∂15-Mar-89 1756 CL-Cleanup-mailer Re: Issue LOCALLY-TOP-LEVEL, v1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 15 Mar 89 17:56:39 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 15 MAR 89 17:24:03 PST
Date: 15 Mar 89 17:23 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue LOCALLY-TOP-LEVEL, v1
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Mon, 13 Mar 89 18:51 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Kim A. Barrett <IIM%ECLA@ECLC.USC.EDU>, cl-cleanup@SAIL.STANFORD.EDU,
cl-compiler@SAIL.STANFORD.EDU
Message-ID: <890315-172403-1288@Xerox>
I don't care what committee you send it to, but since Sandra has already
finished her list of proposals and I'm still working on mine, you might as
well get it on mine. Cleanup has more time, anyway.
It looked like it only needed the minor edit to fix the NO-HOSTING
allusion.
∂15-Mar-89 1941 CL-Compiler-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 15 Mar 89 19:40:55 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Wed, 15 Mar 89 21:39:48 CST id AA08835 for cl-compiler@sail.stanford.edu
Posted-Date: Wed, 15 Mar 89 21:38:06 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA16529; Wed, 15 Mar 89 21:38:06 CST
Date: Wed, 15 Mar 89 21:38:06 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903160338.AA16529@pavo.src.honeywell.com>
To: cl-compiler@sail.stanford.edu
Cc: x3j13@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 13 Mar 89 15:50:07 -0700 <8903132250.AA02499@defun.utah.edu>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
If we permit the compiler to signal warnings for functions where the
compile-time environment signature is different from the function call
being compiled, why do we prohibit it for generic functions?
From COMPILE-ENVIRONMENT-CONSISTENCY:
(3) The compiler *must not* make any additional assumptions about
consistency between the compiletime and runtime environments. In
particular:
(a) The compiler may not ... It is, however,
permissible for the compiler to emit warning messages when
compiling calls to functions that are defined in the compiletime
environment, but where the wrong number or type of arguments
are supplied.
But then in CLOS-MACRO-COMPILATION:
DEFMETHOD:
* The method is not callable at compile-time. If there is a generic
function with the same name at compile-time, compiling a DEFMETHOD
will not add the method to that generic function. The compiler may
perform tests for lambda-list congruence only between the DEFGENERICs
and DEFMETHODs for a given generic function name that appear within
the file being compiled, and not against a generic function of the
same name which exists in the compile-time environment.
∂15-Mar-89 2035 CL-Compiler-mailer Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 15 Mar 89 20:35:47 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA10009; Wed, 15 Mar 89 21:33:36 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA05125; Wed, 15 Mar 89 21:33:33 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903160433.AA05125@defun.utah.edu>
Date: Wed, 15 Mar 89 21:33:31 MST
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
To: alarson@src.honeywell.com (Aaron Larson)
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: alarson@src.honeywell.com (Aaron Larson), Wed, 15 Mar 89 21:38:06 CST
> Date: Wed, 15 Mar 89 21:38:06 CST
> From: alarson@src.honeywell.com (Aaron Larson)
>
> If we permit the compiler to signal warnings for functions where the
> compile-time environment signature is different from the function call
> being compiled, why do we prohibit it for generic functions?
I believe there are two different (although related) issues being
addressed here.
The section from COMPILE-ENVIRONMENT-CONSISTENCY deals with
consistency requirements for function calls. It says the compiler
can't assume you're not going to redefine functions between compile
time and run time.
The section from CLOS-MACRO-COMPILATION deals with consistency between
methods and generic functions. If you read the description of
DEFMETHOD in CLOS chapter 2, it says that an error must be signalled
if there are problems with lambda-list congruency, or if the function
isn't a generic function, and maybe other things too that I can't
remember off the top of my head. The intent of the wording in this
proposal was to clarify that this error signalling should happen at
run time and not compile time, since the methods don't actually get
"added" to the generic function until then, and the generic function
might have been redefined between compile time and run time.
I agree this is confusing, though. To make things worse, there's been
a suggestion for issue COMPILER-DIAGNOSTICS to allow the compiler to
signal a warning whenever it runs into a situation that it can
determine will cause an error to be signalled at run time. I will
make another pass over all three proposals to make sure that they are
all mutually consistent in this respect. Probably this will involve
moving the piece allowing warnings to be signalled from issue
COMPILE-ENVIRONMENT-CONSISTENCY to COMPILER-DIAGNOSTICS, clarifying
that this is only a style warning, and fixing CLOS-MACRO-COMPILATION
to make it more clear that it's talking about the error signalling
required by the specification of DEFMETHOD in CLOS chapter 2 and not
random style warnings issued by the compiler. Sound OK?
-Sandra
-------
∂15-Mar-89 2046 CL-Compiler-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 15 Mar 89 20:46:36 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Wed, 15 Mar 89 22:45:30 CST id AA09273 for cl-compiler@sail.stanford.edu
Posted-Date: Wed, 15 Mar 89 22:43:47 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA16592; Wed, 15 Mar 89 22:43:47 CST
Date: Wed, 15 Mar 89 22:43:47 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903160443.AA16592@pavo.src.honeywell.com>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Wed, 15 Mar 89 21:33:31 MST <8903160433.AA05125@defun.utah.edu>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Sounds like a winner to me.
∂16-Mar-89 0601 X3J13-mailer Re: issue COMPILER-VERBOSITY, version 6
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 06:01:53 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 05:48:37 PST
Date: 16 Mar 89 05:47 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue COMPILER-VERBOSITY, version 6
To: cl-compiler@sail.stanford.edu
cc: x3J13@sail.stanford.edu
Message-ID: <890316-054837-3596@Xerox>
The current practice of this proposal says that one implementation has a
:VERBOSE that is used for what this proposal calls :PRINT, gives no current
examples of :VERBOSE, etc. I'm suspicious of a proposal to add something
that is significantly more complex than what any current implementation
already has.
COMPILE-FILE is significantly more part of the "environment" than LOAD is,
and I think that the less we specify its behavior, the better off we are.
While there are useful programmatic portable invocations of LOAD where
controlling the output behavior portably is important, the case for
portable control of output behavior of COMPILE-FILE is much less strong.
What about environments that support incremental compilation? Where
compilation is handled by a background process? Wouldn't this be
unnecessary junk for them to add?
If we have some doubts about whether some of these 'puppies' are really
useful, shouldn't we leave them behind? Not require them?
Larry
∂16-Mar-89 0645 CL-Compiler-mailer Re: issue CONSTANT-CIRCULAR-COMPILATION, version 7
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 06:44:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 06:39:07 PST
Date: 16 Mar 89 06:38 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue CONSTANT-CIRCULAR-COMPILATION, version 7
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
Mon, 13 Mar 89 09:19:28 -0700
To: cl-compiler@sail.stanford.edu
Message-ID: <890316-063907-3657@Xerox>
I think the 'error terminology' is probably misapplied in the use
"State that the consequences are undefined if an object containing a
circular reference appears as a constant to be compiled."
We speak of "... the consequences are undefined... " in reference to the
consequences of execution of a particular construct during the normal
evaluation process, either in interpreted or compiled code.
The appearance of the object itself does not have undefined consequences, I
don't think. Is it the consequence of attempting to invoke COMPILE or
COMPILE-FILE that is undefined, or is it the consequence of attempting to
execute the result of the COMPILE or COMPILE-FILE that you wish to leave
undefined?
If I say
(defun frob ()
(when nil #1=(nil . #1#)))
(compile 'frob)
(frob)
are the consequences undefined?
Maybe I'm just quibbling.
Larry
∂16-Mar-89 0648 CL-Compiler-mailer Re: issue LOAD-TIME-EVAL, version 11
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 06:48:06 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 06:45:55 PST
Date: 16 Mar 89 06:45 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue LOAD-TIME-EVAL, version 11
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
Mon, 13 Mar 89 09:31:50 -0700
To: cl-compiler@sail.stanford.edu
Message-ID: <890316-064555-3667@Xerox>
Um, I looked for and didn't find a justification for why what was passed at
the last meeting was inadequate. I'm puzzled as to why there are now two
proposals when there was one before, what the differences are between them,
etc.
Can you elucidate? (preferably to X3J13)
Larry
∂16-Mar-89 0651 CL-Compiler-mailer Re: issue QUOTE-SEMANTICS, version 2
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 06:50:39 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 06:48:29 PST
Date: 16 Mar 89 06:47 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue QUOTE-SEMANTICS, version 2
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
Mon, 13 Mar 89 10:21:33 -0700
To: cl-compiler@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890316-064829-3674@Xerox>
Can you explain how QUOTE-SEMANTICS and CONSTANT-COLLAPSING aren't the
addressing the same issue?
∂16-Mar-89 0655 CL-Compiler-mailer Re: issue QUOTE-SEMANTICS, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Mar 89 06:55:47 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA20657; Thu, 16 Mar 89 07:53:34 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA05480; Thu, 16 Mar 89 07:53:32 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903161453.AA05480@defun.utah.edu>
Date: Thu, 16 Mar 89 07:53:30 MST
Subject: Re: issue QUOTE-SEMANTICS, version 2
To: masinter.pa@Xerox.COM
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM, 16 Mar 89 06:47 PST
> Can you explain how QUOTE-SEMANTICS and CONSTANT-COLLAPSING aren't the
> addressing the same issue?
QUOTE-SEMANTICS discusses in what circumstances (COMPILE-FILE only or
COMPILE and EVAL also) it is legitimate for constants to be coalesced
or copied.
CONSTANT-COLLAPSING proposes to change the equivalence relationship
used to compare two constants to see if they can be coalesced from
EQUAL to something more general.
-Sandra
-------
∂16-Mar-89 0708 CL-Compiler-mailer Re: Issue SAFE-CODE, version 1
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 07:08:22 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 07:03:17 PST
Date: 16 Mar 89 07:02 PST
From: masinter.pa@Xerox.COM
Subject: Re: Issue SAFE-CODE, version 1
In-reply-to: Dick Gabriel <RPG@SAIL.Stanford.EDU>'s message of 15 Mar 89
14:51 PST
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>
cc: cl-compiler@SAIL.Stanford.EDU, x3j13@SAIL.Stanford.EDU
Message-ID: <890316-070317-3708@Xerox>
I'm guessing that Moon's objections are more serious than yours.
Frankly, as long as we're playing definitions, I think the problem lies
with
"Define that, formally, the term ``safe code'' is code refers to any
code in which the OPTIMIZE quality for SAFETY has a value of 3."
I don't think this is a good definition. It is probably good to define that
"any code in which the OPTIMIZE quality for SAFETY has a value 3" is "safe
code", but there is other code that is "safe" too.
It seems pretty awkward to say that:
(locally (declare (optimize (safety 0))) (list 1 2 3))
is "unsafe" or "nonsafe" or "potentially non-safe". We could use the words
that way, but it is pretty confusing.
Counter-proposal: say "declared safe" or "not declared safe", since the
issue is not the (English) safety of the code but the declarations in
effect?
∂16-Mar-89 0720 CL-Compiler-mailer Re: issue QUOTE-SEMANTICS, version 2
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 07:20:41 PST
Received: from Semillon.ms by ArpaGateway.ms ; 16 MAR 89 07:17:20 PST
Date: 16 Mar 89 07:16 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue QUOTE-SEMANTICS, version 2
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
Thu, 16 Mar 89 07:53:30 MST
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
cc: masinter.pa@Xerox.COM, cl-compiler@sail.stanford.edu
Message-ID: <890316-071720-3752@Xerox>
So, there are some outcomes of QUOTE-SEMANTICS where CONSTANT-COLLAPSING is moot?
∂16-Mar-89 0632 X3J13-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 06:32:40 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 06:23:30 PST
Date: 16 Mar 89 06:22 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Tue, 14 Mar 89 20:27 EST
To: cl-compiler@sail.stanford.edu
cc: X3J13@sail.stanford.edu
Message-ID: <890316-062330-3633@Xerox>
I think the previous sentiment was more strongly toward removing
COMPILED-FUNCTION rather than tightening its definition. However, in the
heat of the FUNCTION-TYPE discussion, this seemed to be a controversial
backward incompatibility (why not just leave it in, but leave it
unspecified?)
I've extracted some quotes about COMPILED-FUNCTION from the CL-CLEANUP
discussion on FUNCTION-TYPE. Of course, these are taken out of context...
Return-Path: <@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 02 MAR 87 21:29:49 PST
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 2 Mar
87 21:27:23 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 82Date: Tue, 3
Mar 87 00:26 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Tue, 3 Mar 87 00:26 EST
It might be wise to add LEXICAL-CLOSURE and INTERPRETED-FUNCTION data
types, to go along with the COMPILED-FUNCTION type that already exists.
These three would be disjoint subtypes of FUNCTION, but not necessarily
an exhaustive partition. There might be other ways to slice the space
of types, since it's not so clear what a function not inside a closure
is good for. Alternatively we could flush COMPILED-FUNCTION and say
that the subtypes of FUNCTION are all implementation-dependent. But I
think having COMPILED-FUNCTION without the others is weird.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:FAHLMAN@C.CS.CMU.EDU>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 08 MAR 87 21:56:23 PST
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 8 Mar 87
21:53:10 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 9 Mar 87 00:53:51-EST
Date: Mon, 9 Mar 87 00:53 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Probably we should explicitly name COMPILED-FUNCTION and
INTERPRETED-FUNCTION as subtypes of FUNCTION, and make TYPEP work for
them.
- - - - - - - - -
Return-Path: <RPG@SAIL.STANFORD.EDU>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 08 MAR 87 23:54:05 PST
Date: 08 Mar 87 23:51 PST
From: Dick Gabriel <RPG@SAIL.STANFORD.EDU>
Possibly these should not be required to be pairwise disjoint (?).
I think we shouldn't presume that all implementations implement
functions as closures. I can imagine an implementation with
COMPILED-FUNCTIONs, INTERPRETED-FUNCTIONs, COMPILED-CLOSUREs,
and INTERPRETED-CLOSUREs.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:FAHLMAN@C.CS.CMU.EDU>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 09 MAR 87 08:07:46 PST
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 9 Mar 87
08:01:49 PST
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Mon 9 Mar 87 10:57:49-EST
Date: Mon, 9 Mar 87 10:57 EST
From: "Scott E. Fahlman" <Fahlman@C.CS.CMU.EDU>
Well, these make sense only in systems that do support both compiled and
interpreted code. In compiler-only or interpreter-only systems, I guess
the best move would be to say that every function is a member of both of
these subtypes: it is both a fast function and a slow function.
Now you're the one who is letting the user see internal stuff that is
none of his concern. All of these functions are closures, in that they
no longer have any free variables waiting to be closed. In some cases,
there may have been none in the first place, and implementors may want
to use some efficient internal form in such cases, but is there any
reason the user needs to know that? A confusing concept that does him
no good (I think).
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 10 MAR 87 07:54:56 PST
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 10 Mar
87 07:48:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 89098; Tue
10-Mar-87 01:57:50 EST
Date: Tue, 10 Mar 87 01:57 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
... I vacillate between
saying that all of the subtypes of FUNCTION are implementation-dependent
and shouldn't be standardized (thus COMPILED-FUNCTION should be
removed), and saying that programs might want to know this information,
so all the plausible subtypes should have standard names, even if they
aren't distinct in some implementations. The only thing I feel strongly
and consistently about is that COMPILED-FUNCTION should not be the only
standardized subtype of FUNCTION; it should either acquire some siblings
or go away.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:KMP@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 13 MAY 87 00:13:57 PDT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 13 May
87 00:12:36 PDT
Received: from TSUKUBA.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM
via CHAOS with CHAOS-MAIL id 138655; Wed 13-May-87 03:10:55 EDT
Date: Wed, 13 May 87 03:10 EDT
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
* It seems to me that we might as well go ahead and create types
INTERPRETED-FUNCTION and COMPILED-FUNCTION since the combination of
the FUNCTION type and the COMPILED-FUNCTION-P predicate already
implements
this distinction. Perhaps eventually COMPILED-FUNCTION-P could be
flushed.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:FAHLMAN@C.CS.CMU.EDU>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 17 MAY 87 19:32:45 PDT
Received: from C.CS.CMU.EDU by SAIL.STANFORD.EDU with TCP; 17 May 87
19:31:22 PDT
Received: ID <FAHLMAN@C.CS.CMU.EDU>; Sun 17 May 87 22:30:44-EDT
Date: Sun, 17 May 87 22:30 EDT
Message-ID: <FAHLMAN.12303231779.BABYL@C.CS.CMU.EDU>
Sender: FAHLMAN@C.CS.CMU.EDU
One possibility is not to define any of these and to eliminate
COMPILED-FUNCTION-P. That's what I proposed in version 3. The other
possibility is to define COMPILED-FUNCTION and INTERPRETED-FUNCTION as
subtypes of FUNCTION, but then we have to spell out what happens in
implementations that have only one internal representation or that have
more than two -- raw interpreted, transformed, and fully compiled, for
example. Then there's the question of whether closures are, or can be,
a separate subtype. In some sense, all true functions are closures,
since to get one you close a lambda expression in some lexical
environment. However, we might want to reserve the word "closure" for
functions that actually capture some part of the lexical context outside
the function itself, and to create CLOSURE types based on this idea.
In my view, we are better off avoiding this whole thing and leaving it
to the individual implementations.
- - - - - - - - -
Date: 29 May 87 21:18 PDT
Subject: Issue: FUNCTION-TYPE (version 4)
From: Masinter.pa
Proposal FUNCTION-TYPE:REDEFINE
...
No sub-types of FUNCTION are defined in Common Lisp, but implementations
are free to define subtypes of FUNCTION. Examples might be
COMPILED-FUNCTION, INTERPRETED-FUNCTION, and so on. Note that this
is a change from the current Common Lisp definition which explicitly
defines a COMPILED-FUNCTION type. This proposal removes the predicate
COMPILED-FUNCTION-P from the standard language.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:Moon@STONY-BROOK.SCRC.Symbolics.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 01 JUN 87 21:23:10 PDT
Received: from SCRC-STONY-BROOK.ARPA by SAIL.STANFORD.EDU with TCP; 1 Jun
87 21:21:48 PDT
Received: from EUPHRATES.SCRC.Symbolics.COM by
STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 161267; Tue
2-Jun-87 00:11:30 EDT
Date: Tue, 2 Jun 87 00:11 EDT
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
This proposal removes the predicate
COMPILED-FUNCTION-P from the standard language.
If it also removes the COMPILED-FUNCTION type-specifier, say so here.
- - - - - - - - -
Return-Path: <@SAIL.STANFORD.EDU:Masinter.pa@Xerox.COM>
Received: from SAIL.STANFORD.EDU by Xerox.COM ; 13 JUL 87 12:58:35 PDT
Received: from XEROX.COM by SAIL.STANFORD.EDU with TCP; 13 Jul 87 12:54:07
PDT
Received: from Cabernet.ms by ArpaGateway.ms ; 13 JUL 87 12:54:07 PDT
Date: 13 Jul 87 12:53 PDT
From: Masinter.pa
... My notes [from X3J13 meeting] include ... that we be more consistent
about justifying removing COMPILED-FUNCTION-P (i.e., why bother?) ...
- - - - - - - - -
Date: 23 Oct 87 11:51 PDT
From: Masinter.pa
Subject: Issue: FUNCTION-TYPE (Version 6)
here is a revised version... I left COMPILED-FUNCTION and
COMPILED-FUNCTION-P as subtypes of FUNCTION.
...
Proposal FUNCTION-TYPE:STRICT-REDEFINITION
...
The COMPILED-FUNCTION subtype of FUNCTION is defined; implementations are
free to define other subtypes of FUNCTION, e.g., INTERPRETED-FUNCTION.
- - - - - - - - -
(wording preserved through several iterations)
- - - - - - - - -
Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanup↑.pa
Received: from SAIL.Stanford.EDU by Xerox.COM ; 16 FEB 88 09:41:39 PST
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Feb 88
09:39:23 PST
Received: by cs.utah.edu (5.54/utah-2.0-cs)
id AA23751; Tue, 16 Feb 88 10:39:08 MST
Received: by orion.utah.edu (5.54/utah-1.0-slave)
id AA25191; Tue, 16 Feb 88 10:39:04 MST
From: sandra%orion@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8802161739.AA25191@orion.utah.edu>
Date: Tue, 16 Feb 88 10:39:02 MST
Also, I have a question about 1b, where it states that COMPILED-FUNCTION
is a subtype of FUNCTION. Does this imply that it must be a *proper*
subtype? For example, in the Lisp I've been working on sporadically for
my Atari, the interpreted version of (FUNCTION (LAMBDA ...)) returns a
compiled function object (it's a closure which will apply the lambda
expression to the function arguments). Likewise I can conceive of
implementations which compile everything and don't have an "interpreter"
at all. I think this needs to be clarified.
- - - - - - - - -
Return-Path: <CL-Cleanup-mailer@SAIL.Stanford.EDU>
Redistributed: xerox-cl-cleanup↑.pa
Received: from SAIL.Stanford.EDU by Xerox.COM ; 19 FEB 88 14:37:22 PST
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 19 Feb 88 14:34:11
PST
Received: from Cabernet.ms by ArpaGateway.ms ; 19 FEB 88 14:17:33 PST
Date: 19 Feb 88 14:17 PST
From: Masinter.pa
I intended not to require that it not be a "proper" subtype in the sense
that
there may be no data items that are FUNCTIONP but not COMPILED-FUNCTIONP.
This can be clarified.
- - - - - - - - -
Return-Path: <edsel!jonl@labrea.Stanford.EDU>
Received: from labrea.Stanford.EDU by Xerox.COM ; 24 FEB 88 10:14:38 PST
Received: by labrea.Stanford.EDU; Wed, 24 Feb 88 09:35:20 PST
Received: from bhopal.lucid.com by edsel id AA21578g; Wed, 24 Feb 88
10:03:43 PST
Received: by bhopal id AA26979g; Wed, 24 Feb 88 10:09:26 PST
Date: Wed, 24 Feb 88 10:09:26 PST
From: Jon L White <edsel!jonl@labrea.Stanford.EDU>
Lucid Common Lisp distinguishes "compiled" closures which exist for the
purpose of supporting entry into the interpreter from functions which are
truly compiled. It only takes a bit in a header word. If an
implementation
really doesn't support an interpreter, then having every function be
COMPILED-FUNCTIONP doesn't sound like much of a loss.
But most implementations in fact do support an interpreter -- which
typically runs code at anywhere from 30 to 600 times slower than when
compiled. Thus it seems reasonable to require COMPILED-FUNCTIONP in
those implementations to be false on, say,
(eval '#'(lambda (x) (list x)))
no matter what underlying technique is used to support interpreter
closures.
- - - - - - - - -
Date: 4 Sep 88 13:39 PDT
From: Masinter.pa
Subject: Issue: FUNCTION-TYPE (version 12)
line-fold: NO
This is the final version of the FUNCTION-TYPE issue, as passed at the June
88 X3J13 meeting; that is, it incorporates the amendments that were adopted
before the issue was adopted.
...
1b. Define that the type COMPILED-FUNCTION is a subtype of FUNCTION.
Implementations are free to define other subtypes of FUNCTION.
∂16-Mar-89 0731 CL-Compiler-mailer Re: Issue SAFE-CODE, version 1
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Mar 89 07:31:24 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA22139; Thu, 16 Mar 89 08:29:07 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA05531; Thu, 16 Mar 89 08:29:04 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903161529.AA05531@defun.utah.edu>
Date: Thu, 16 Mar 89 08:29:03 MST
Subject: Re: Issue SAFE-CODE, version 1
To: masinter.pa@Xerox.COM
Cc: Dick Gabriel <RPG@SAIL.Stanford.EDU>, cl-compiler@SAIL.Stanford.EDU
In-Reply-To: masinter.pa@Xerox.COM, 16 Mar 89 07:02 PST
Hmmm. I thought this would be the least controversial of any of our
issues!
Seriously folks, I believe the intent of this proposal was *only* to
say that (OPTIMIZE (SAFETY 3)) is the only magic incantation you need
to be guaranteed to get "safe code". Some of the objections to the
way it's stated seem valid to me, but let's not try to read more into
the issue than was intended.
If anybody wants to submit a new version which fixes the wording, feel
free.
-Sandra
-------
∂16-Mar-89 0737 CL-Compiler-mailer Re: issue QUOTE-SEMANTICS, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Mar 89 07:37:26 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA22462; Thu, 16 Mar 89 08:35:12 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA05545; Thu, 16 Mar 89 08:35:09 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903161535.AA05545@defun.utah.edu>
Date: Thu, 16 Mar 89 08:35:08 MST
Subject: Re: issue QUOTE-SEMANTICS, version 2
To: masinter.pa@Xerox.COM
Cc: sandra%defun@cs.utah.edu (Sandra J Loosemore),
cl-compiler@sail.stanford.edu
In-Reply-To: masinter.pa@Xerox.COM, 16 Mar 89 07:16 PST
> So, there are some outcomes of QUOTE-SEMANTICS where
> CONSTANT-COLLAPSING is moot?
No. Coalescing of constants by COMPILE-FILE will be permitted under
all of the QUOTE-SEMANTICS proposals.
Again, all CONSTANT-COLLAPSING:GENERALIZE does is propose using a
different relationship than EQUAL for comparing two objects to see if
they are equivalent. If this proposal fails, coalescing of EQUAL
objects will still be permitted.
-Sandra
-------
∂16-Mar-89 0801 CL-Compiler-mailer Re: issue EVAL-WHEN-NON-TOP-LEVEL, version 6
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 08:01:12 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 16 MAR 89 07:53:04 PST
Date: 16 Mar 89 07:52 PST
From: masinter.pa@Xerox.COM
Subject: Re: issue EVAL-WHEN-NON-TOP-LEVEL, version 6
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
Mon, 13 Mar 89 16:42:54 -0700
To: cl-compiler@sail.stanford.edu
Message-ID: <890316-075304-3840@Xerox>
I like the intent of EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL but have some
wording quibbles.
If "the file compiler" means COMPILE-FILE, why not say COMPILE-FILE? I'm
sure you don't mean to refer to, say, a C compiler written in Common Lisp,
even though it might be a file compiler.
Instead of "a top-level form in the file compiler", say "a top-level form
processed by COMPILE-FILE." In any case, you don't mean to talk about one
of the expressions that occur in the source code that defines COMPILE-FILE.
For an EVAL-WHEN form that is not a top-level form in the file compiler
(that is, one of: in the interpreter; in COMPILE; or in the file
compiler but not at top-level) ...
The "(that is, ..." clauses are neither exhaustive or appropriate. I think
you really mean "all other cases". I don't think you can have an EVAL-WHEN
that is 'at top level' to COMPILE since COMPILE takes functions or lambda
expressions. It's possible to think of a version of COMPILE-FILE that
produces things that are then 'interpreted' to some extent (byte-code
interpreter, for example).
Try,
For an EVAL-WHEN that is not a top-level form processed by
COMPILE-FILE,
-- - - - - - - - - -
I'm not too opposed to :EXECUTE, :COMPILE and :LOAD as keywords, but don't
see the need for the extra verbosity of :COMPILE-TOPLEVEL or
:LOAD-TOPLEVEL. There are other ways to emphasize the "toplevel" aspect;
e.g., put ***WARNING*** in your reference manual.
∂16-Mar-89 0928 CL-Compiler-mailer Issue SAFE-CODE, version 1
To: cl-compiler@SAIL.Stanford.EDU
CC: x3j13@SAIL.Stanford.EDU
From: Dick Gabriel <RPG@SAIL.Stanford.EDU>
The point of these definitions is to lay out terminology that
enables programmers to know with certainty on what ground they stand
with respect to the specification. ``Safe code'' is a technical term
that means that the code was ``processed'' under this declaration.
This means intuitively that it is as safe (English word) as it can get.
But it also means that it is ``safe code'' in the CL jargon, and eveything
we say about safe code there is also true of it.
The meaning of safe code (English phrase), as in ``as safe as it can
get,'' is spelled out in the specification as the sequence of statements
we make about the attributes of safe code. It might be that some or all of
those attributes apply to code processed under lower safety optimization
levels, but the programmer can be sure only when the highest safety level
is used.
I think Moon's problem is that the usual practice is to borrow English
words for these technical terms, and that works fine until the
negation of the term is needed. We want some word to mean ``not `safe' ''.
``Unsafe'' is an available English word that does not mean the
complement of ``safe'', it means the reverse of safe. Thus, the parallel
senses of the technical pair ``safe/unsafe'' are not the same as the
vernacular pair safe/unsafe.
Also, the definitions of the terms point out that what is defined as
``unsafe code'' might actually be exactly as safe (English) as ``safe code.''
-rpg-
∂16-Mar-89 0919 CL-Compiler-mailer Re: issue EVAL-WHEN-NON-TOP-LEVEL, version 6
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 09:19:50 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA13903; Thu, 16 Mar 89 09:20:26 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA13867; Thu, 16 Mar 89 09:16:34 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA03194; Thu, 16 Mar 89 09:20:08 PST
Date: Thu, 16 Mar 89 09:20:08 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903161720.AA03194@clam.sun.com>
To: cl-compiler@sail.stanford.edu, sandra%defun@cs.utah.edu
Subject: Re: issue EVAL-WHEN-NON-TOP-LEVEL, version 6
Ack. What happened to any version that aims to "fix nesting"?
That problem has to be the main reason I've ever been
interested in this issue.
Suppose programmer A defines a macro DEFINE-FROB that expands into
(EVAL-WHEN (COMPILE LOAD EVAL) . . . )
Now suppose that for some reason programmer B, a user of FROBs,
desires to only define a frob at load time, and writes:
(EVAL-WHEN (LOAD)
(DEFINE-FROB . . . ))
As defined in CLtL and in EVAL-WHEN-NON-TOP-LEVEL:GENERALIZE-EVAL,
the frob gets defined at compile-time (too), even though programmer
B specified only LOAD-time.
Is it unreasonable to try to delay such a thing until load time?
Am I wrong about what would happen in this scenario?
What *is* the story here?
-Cris
∂16-Mar-89 0941 CL-Compiler-mailer Re: issue EVAL-WHEN-NON-TOP-LEVEL, version 6
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Mar 89 09:40:51 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA27198; Thu, 16 Mar 89 10:38:30 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA05681; Thu, 16 Mar 89 10:38:28 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903161738.AA05681@defun.utah.edu>
Date: Thu, 16 Mar 89 10:38:27 MST
Subject: Re: issue EVAL-WHEN-NON-TOP-LEVEL, version 6
To: cperdue@Sun.COM (Cris Perdue)
Cc: cl-compiler@sail.stanford.edu, sandra%defun@cs.utah.edu
In-Reply-To: cperdue@Sun.COM (Cris Perdue), Thu, 16 Mar 89 09:20:08 PST
> Date: Thu, 16 Mar 89 09:20:08 PST
> From: cperdue@Sun.COM (Cris Perdue)
>
> Ack. What happened to any version that aims to "fix nesting"?
> That problem has to be the main reason I've ever been
> interested in this issue.
I'm well aware that not everybody likes this proposal. However,
nobody has given me anything specific to include as an alternate
proposal.
My own personal position on this issue, as I have several times in the
past, is that I would also like to fix the nesting behavior. However,
since I got several negative comments on the alternate proposal I
circulated myself, and nobody explicitly expressed support for it, I
decided there was little chance of us reaching consensus on it, and
that it wouldn't be worthwhile for me to pursue it further.
If you (or anybody else) absolutely positively cannot live with the
GENERALIZE-EVAL proposal, *and* you have something specific to propose
instead, by all means go ahead and do so. The alternative would be to
say nothing on this issue, which I think would be far worse than
GENERALIZE-EVAL.
-Sandra
-------
∂16-Mar-89 0958 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 09:58:47 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via INTERNET with SMTP id 124445; 16 Mar 89 12:31:52 EST
Date: Thu, 16 Mar 89 12:31 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
To: masinter.pa@xerox.com
cc: cl-compiler@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: <890316-062330-3633@Xerox>
Message-ID: <19890316173142.7.BARMAR@OCCAM.THINK.COM>
I'll just reiterate something I said at one of the meetings. One
portable use I can think of for the COMPILED-FUNCTION type is as a
declaration to allow compiler optimization. If a function knows (or
requires) that a parameter is a compiled function it can declare that
and the implementation may be able to optimize the FUNCALL better.
Another thing I just thought of is something like:
(when (typep f '(and function (not compiled-function)))
(setq f (compile nil f)))
This doesn't actually work because COMPILE isn't required to accept
lexical closures (well, at least it doesn't accept them in Genera 7.2),
but they satisfy the type specifier, but it would be nice if there were
a standard set of primitives that would allow one to write something
that does what the above tries to do.
barmar
∂16-Mar-89 1041 CL-Compiler-mailer Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE
Received: from ti.com by SAIL.Stanford.EDU with TCP; 16 Mar 89 10:41:10 PST
Received: by ti.com id AA05571; Thu, 16 Mar 89 12:34:15 CST
Received: from Kelvin by tilde id AA13331; Thu, 16 Mar 89 12:28:00 CST
Message-Id: <2815064795-5736240@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Thu, 16 Mar 89 12:26:35 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Cc: cl-compiler@SAIL.STANFORD.EDU
Subject: Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE
In-Reply-To: Msg of 14 Mar 89 0738 PST from System Files <SYS@SAIL.Stanford.EDU>
> ... It makes me wonder whether we
> > should just permit top-level DECLAREs, but then _it_ would need special
> > handling by the compiler since a macro definition would confuse the
> > semantics of local declarations, so you don't win.
>
> I don't understand the last sentence. What kind of macro definition?
> Can you give an example?
I just meant that we don't want to define DECLARE as a macro, and that
having a special form that is treated specially by the compiler at top
level doesn't seen any better than a function that is treated specially.
∂16-Mar-89 1046 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Mar 89 10:46:05 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA06443; Thu, 16 Mar 89 13:43:51 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA07257; Thu, 16 Mar 89 13:42:10 EST
Message-Id: <8903161842.AA07257@mist.>
To: Barry Margolin <barmar@FAFNIR.THINK.COM>
Cc: cl-compiler@sail.stanford.edu
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
In-Reply-To: Your message of Thu, 16 Mar 89 12:31:00 -0500.
<19890316173142.7.BARMAR@OCCAM.THINK.COM>
Date: Thu, 16 Mar 89 13:42:07 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Thu, 16 Mar 89 12:31 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Another thing I just thought of is something like:
(when (typep f '(and function (not compiled-function)))
(setq f (compile nil f)))
This doesn't actually work because COMPILE isn't required to accept
lexical closures (well, at least it doesn't accept them in Genera 7.2),
but they satisfy the type specifier, but it would be nice if there were
a standard set of primitives that would allow one to write something
that does what the above tries to do.
One of Kent's points in earlier discussion was that it should (read
MUST) be safe to blindly apply to COMPILE to any symbol with a
function definition. I thought there was general agreement on this.
If the lastest draft contradicts this then it needs to be fixed.
∂16-Mar-89 1111 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Mar 89 11:11:32 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA00971; Thu, 16 Mar 89 12:05:45 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA05839; Thu, 16 Mar 89 12:05:35 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903161905.AA05839@defun.utah.edu>
Date: Thu, 16 Mar 89 12:05:34 MST
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
To: Dan L. Pierson <pierson@mist.encore.com>
Cc: Barry Margolin <barmar@FAFNIR.THINK.COM>, cl-compiler@sail.stanford.edu
In-Reply-To: Dan L. Pierson <pierson@mist.encore.com>, Thu, 16 Mar 89 13:42:07 EST
> Date: Thu, 16 Mar 89 13:42:07 EST
> From: Dan L. Pierson <pierson@mist.encore.com>
>
> One of Kent's points in earlier discussion was that it should (read
> MUST) be safe to blindly apply to COMPILE to any symbol with a
> function definition. I thought there was general agreement on this.
> If the lastest draft contradicts this then it needs to be fixed.
The current wording (from proposal COMPILE-ARGUMENT-PROBLEMS) says
"it is an error". My recollection is that we agreed to an editorial
change to "the consequences are unspecified", assuming the error
terminology ever gets sorted out.
Now that I think about the interaction between the two proposals, it
does seem like there is a problem -- we can't require a
COMPILED-FUNCTION to be returned and leave the behavior unspecified at
the same time. I think we need to do one of two things:
(1) Require COMPILE to signal an error if it can't return a
COMPILED-FUNCTION.
(2) Say that COMPILE is required to return a COMPILED-FUNCTION only
in the situations that are not unspecified.
Any further thoughts on this? My personal leanings are towards
signalling an error.
-Sandra
-------
∂16-Mar-89 1117 CL-Compiler-mailer issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 11:16:55 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558656; Thu 16-Mar-89 14:13:55 EST
Date: Thu, 16 Mar 89 14:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
To: Aaron Larson <alarson@src.honeywell.com>
cc: cl-compiler@sail.stanford.edu, x3j13@sail.stanford.edu
In-Reply-To: <8903160338.AA16529@pavo.src.honeywell.com>
Message-ID: <19890316191343.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 15 Mar 89 21:38:06 CST
From: alarson@src.honeywell.com (Aaron Larson)
If we permit the compiler to signal warnings for functions where the
compile-time environment signature is different from the function call
being compiled, why do we prohibit it for generic functions?
I would say that what CLOS-MACRO-COMPILATION (which I have not reviewed yet)
is clearly incorrect. Perhaps CLOS-MACRO-COMPILATION was trying only to rule
out signalling an error for a lack of lambda-list congruency between
compile-time and run-time, but went overboard and ruled out warnings
as well. I think warnings in this circumstance can be desirable, but
errors are certainly wrong.
∂16-Mar-89 1121 CL-Compiler-mailer Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 11:21:28 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558661; Thu 16-Mar-89 14:17:32 EST
Date: Thu, 16 Mar 89 14:17 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue COMPILE-ENVIRONMENT-CONSISTENCY, version 4
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@sail.stanford.edu
In-Reply-To: <8903142246.AA03773@defun.utah.edu>
Message-ID: <19890316191734.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 14 Mar 89 15:46:00 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Date: Tue, 14 Mar 89 16:37 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> The proposal says:
> Except where some other behavior is explicitly stated, when
> the compiletime and runtime definitions are different, it is
> unspecified which will prevail within the compiled code.
>
> This means that either the compiletime or the runtime definition
> will prevail, but nothing else can happen. It must also be
> permissible to signal an error complaining about the discrepancy.
The very first version of this proposal said "it is an error" here,
back before we had started talking seriously about adopting new error
terminology. There was some discussion about it after that, the
consensus of which seemed to be that the right behavior should really
be "one or the other".
I personally don't see anything wrong with allowing (but not
requiring) an error to be signalled, now that we seem to have agreed
that isn't inconsistent with the term "unspecified".
with the term "the consequences are unspecified."
Then let's amend the proposal to permit signalling an error. As it
currently reads, it does not permit that. Or if you prefer, amend
the proposal to say
Except where some other behavior is explicitly stated, when
the compiletime and runtime definitions are different, the
consequences are unspecified.
∂16-Mar-89 1122 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Mar 89 11:22:03 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA07205; Thu, 16 Mar 89 14:19:53 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA07381; Thu, 16 Mar 89 14:18:12 EST
Message-Id: <8903161918.AA07381@mist.>
To: "sandra%defun@cs.utah.edu"@Multimax.encore.com (Sandra J Loosemore)
Cc: Barry Margolin <barmar@FAFNIR.THINK.COM>, cl-compiler@sail.stanford.edu
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
In-Reply-To: Your message of Thu, 16 Mar 89 12:05:34 -0700.
<8903161905.AA05839@defun.utah.edu>
Date: Thu, 16 Mar 89 14:18:10 EST
From: Dan L. Pierson <pierson@mist.encore.com>
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Date: Thu, 16 Mar 89 12:05:34 MST
> Date: Thu, 16 Mar 89 13:42:07 EST
> From: Dan L. Pierson <pierson@mist.encore.com>
>
> One of Kent's points in earlier discussion was that it should (read
> MUST) be safe to blindly apply to COMPILE to any symbol with a
> function definition. I thought there was general agreement on this.
> If the lastest draft contradicts this then it needs to be fixed.
The current wording (from proposal COMPILE-ARGUMENT-PROBLEMS) says
"it is an error". My recollection is that we agreed to an editorial
change to "the consequences are unspecified", assuming the error
terminology ever gets sorted out.
Now that I think about the interaction between the two proposals, it
does seem like there is a problem -- we can't require a
COMPILED-FUNCTION to be returned and leave the behavior unspecified at
the same time. I think we need to do one of two things:
(1) Require COMPILE to signal an error if it can't return a
COMPILED-FUNCTION.
(2) Say that COMPILE is required to return a COMPILED-FUNCTION only
in the situations that are not unspecified.
Any further thoughts on this? My personal leanings are towards
signalling an error.
What I (and believe Kent) want is a guarantee that it won't signal an
error; if nothing else works COMPILE will simply apply #'IDENTITY to
the symbol's function. Specifically, it should be legal and safe to
attempt to speed up my current program(s) by doing:
(DO-SYMBOLS (SYM <my-package>)
(WHEN (FBOUNDP SYM) (COMPILE SYM)))
∂16-Mar-89 1147 CL-Compiler-mailer Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 11:46:48 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558701; Thu 16-Mar-89 14:43:54 EST
Date: Thu, 16 Mar 89 14:43 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@sail.stanford.edu, Moon@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <8903142211.AA03724@defun.utah.edu>
Message-ID: <19890316194352.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
This message is just about the environment of MACROLET issue.
Date: Tue, 14 Mar 89 15:11:20 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Date: Tue, 14 Mar 89 15:58 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> Clarify
> that all defining macros which create functional objects (including
> DEFMACRO, DEFTYPE, DEFINE-SETF-METHOD, and the complex form of
> DEFSETF, as well as DEFUN) must ensure that those functions are
> defined in the lexical environment in which the defining form is
> evaluated.
>
> I strongly believe that MACROLET must be consistent with this, which
> would be a change. Has that been dealt with as a separate issue? If
> not, it should either be added to this issue or brought up as a
> separate issue, with the interdependency noted in both writeups to
> minimize the chance of an inconsistent vote.
The problem with MACROLET is that it defines the macro functions at
compile time even if it appears at non-top-level, while all the other
ones listed only do so at top-level. Non-top-level environments are
not guaranteed to be "complete" at compile time; bindings of functions
and variables don't exist yet. I suppose we could say that trying to
refer to those functions and variables in the macro functions is an
error of some variety.
That's what I had in mind. I believe the implementation of such error
checking is extremely simple (although I admit there might be
implementations that I don't know about where it would be difficult).
I'd most prefer that an error must be signalled, somewhat less prefer
that the consequences be unspecified, and least prefer that the
macro functions use a special lexical environment specifically defined
to be current in the macros and declarations, but null in the symbols,
functions, and blocks.
Upon reflection I think MACROLET would better be handled as a separate
issue. Has this been discussed and assigned an issue name already?
The basic question is whether DEFMACRO macros and MACROLET macros should
be consistent in the lexical environment of their body, or whether
MACROLET macros should use the null lexical environment, unlike anything
else. If there is not already anything for this, let me know and I
will write it up. Let me know whether it should go to the compiler
committee or the cleanup committee.
In any case, this would be a somewhat more incompatible change than
what the proposal currently says. Lucid, for example, evaluates
DEFMACRO macro functions in the lexical environment that the DEFMACRO
appears (in spite of what CLtL says), but always evaluates MACROLET
macro functions in a null lexical environment.
I think this is a rather narrow attitude on compatibility. What you
seem to have just said is that it's more important for the standard to
be compatible with whatever Lucid's current release does than for the
standard to be self-consistent; I doubt that even most people at Lucid
would agree with that.
∂16-Mar-89 1157 CL-Compiler-mailer Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 11:55:35 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558714; Thu 16-Mar-89 14:52:53 EST
Date: Thu, 16 Mar 89 14:52 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue DEFINING-MACROS-NON-TOP-LEVEL, version 8
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@sail.stanford.edu
In-Reply-To: <8903142211.AA03724@defun.utah.edu>
Message-ID: <19890316195255.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
This message is just about the issue of the order of non-top-level
subforms of a top-level form.
Date: Tue, 14 Mar 89 15:11:20 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Date: Tue, 14 Mar 89 15:58 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> The order in which
> non-top-level subforms of a top-level form are processed by the
> compiler is explicitly left unspecified.
>
> I can't figure out what this means and the example in the rationale
> section that purports to explain this does not shed any light, since in
> the example there is no change of order of evaluation.
I don't know how to explain this any more clearly -- what's in the
current version of the proposal is about the third attempt I've made.
Well, here goes a fourth attempt.
Suppose I have a top-level DEFMACRO at the top of the file. Item (3)
guarantees that this DEFMACRO will be processed before any top-level
forms that appear textually after it. That means I can refer to the
DEFMACRO in those subsequent forms and guarantee that the compiler has
already "seen" the macro definition. The same rule applies to any
other defining macros that do compile-time magic at top-level.
Now suppose expanding this macro has some side-effects, such as
SETQ'ing a special variable. If I have two calls to the macro at
top-level, I can reliably depend on the side-effects happening in the
same order that the calls appear textually. But, the other thing that
item (3) says is that if the two macro calls are embedded at
non-top-level, I can't rely on the order in which the compiler will
expand them.
This explanation is much clearer. Nothing in the explanation that I
couldn't figure out indicated that it had anything to do with macro
expansion; that was the missing information. Could you amend the
proposal to clarify this? Also I found the phrase "non-top-level
subforms of a top-level form" confusing; I wonder if it would work
better to say that the order of expansion of macros is unspecified
for all forms other than top-level forms, i.e. list the cases where
the order is specified and don't try to list the cases where the
order is not specified.
I agree this could be made into a separate issue and be expanded to
include a statement that processing of top-level forms is interleaved
with reading. It had more to do with this issue when the definition
of top-level appeared here.
I still think point (3) should be moved to be together with the rest
of the definition of top-level.
∂16-Mar-89 1213 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:12:51 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA03572; Thu, 16 Mar 89 13:09:15 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA05971; Thu, 16 Mar 89 13:09:13 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903162009.AA05971@defun.utah.edu>
Date: Thu, 16 Mar 89 13:09:11 MST
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
To: Dan L. Pierson <pierson@mist.encore.com>
Cc: Barry Margolin <barmar@FAFNIR.THINK.COM>, cl-compiler@sail.stanford.edu
In-Reply-To: Dan L. Pierson <pierson@mist.encore.com>, Thu, 16 Mar 89 14:18:10 EST
> Date: Thu, 16 Mar 89 14:18:10 EST
> From: Dan L. Pierson <pierson@mist.encore.com>
>
> What I (and believe Kent) want is a guarantee that it won't signal an
> error; if nothing else works COMPILE will simply apply #'IDENTITY to
> the symbol's function.
If this is the position people really want to adopt, I think we ought
to flush the COMPILED-FUNCTION type. I can't imagine it would be
very useful in declarations if we always allow COMPILE to be a no-op
and never require it to return a COMPILED-FUNCTION.
I was going to restore the FLUSH proposal to this issue anyway, since
some people have now expressed an interest in seeing it back.
I still think that the minimum requirements for compilation specified in
the proposal should apply to COMPILE-FILE, regardless of what happens
to COMPILE and COMPILED-FUNCTION.
-Sandra
-------
∂16-Mar-89 1217 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from Aquinas.Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:16:53 PST
Received: from OCCAM.THINK.COM by Aquinas.Think.COM via CHAOS with CHAOS-MAIL id 124449; Thu 16-Mar-89 15:06:16 EST
Date: Thu, 16 Mar 89 15:06 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
To: Dan L. Pierson <pierson@mist.encore.com>
cc: cl-compiler@sail.stanford.edu
In-Reply-To: <8903161842.AA07257@mist.>
Message-ID: <19890316200608.9.BARMAR@OCCAM.THINK.COM>
Date: Thu, 16 Mar 89 13:42:07 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Thu, 16 Mar 89 12:31 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Another thing I just thought of is something like:
(when (typep f '(and function (not compiled-function)))
(setq f (compile nil f)))
This doesn't actually work because COMPILE isn't required to accept
lexical closures (well, at least it doesn't accept them in Genera 7.2),
but they satisfy the type specifier, but it would be nice if there were
a standard set of primitives that would allow one to write something
that does what the above tries to do.
One of Kent's points in earlier discussion was that it should (read
MUST) be safe to blindly apply to COMPILE to any symbol with a
function definition. I thought there was general agreement on this.
If the lastest draft contradicts this then it needs to be fixed.
I don't know what it says. However, I didn't apply COMPILE to a symbol,
I applied it to NIL and a function, which means that the anonymous,
interpreted function should be compiled.
Actually, now I'm also a bit confused. Since we passed the
FUNCTION-TYPE proposal, is the second argument to COMPILE supposed to be
a lambda expression or a function? Should I have said (compile nil
(source-code f)) ?
barmar
∂16-Mar-89 1225 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:25:22 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA07963; Thu, 16 Mar 89 15:23:04 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA07511; Thu, 16 Mar 89 15:21:24 EST
Message-Id: <8903162021.AA07511@mist.>
To: "sandra%defun@cs.utah.edu"@multimax.encore.com (Sandra J Loosemore)
Cc: Barry Margolin <barmar@FAFNIR.THINK.COM>, cl-compiler@sail.stanford.edu
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
In-Reply-To: Your message of Thu, 16 Mar 89 13:09:11 -0700.
<8903162009.AA05971@defun.utah.edu>
Date: Thu, 16 Mar 89 15:21:22 EST
From: Dan L. Pierson <pierson@mist.encore.com>
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Date: Thu, 16 Mar 89 13:09:11 MST
> Date: Thu, 16 Mar 89 14:18:10 EST
> From: Dan L. Pierson <pierson@mist.encore.com>
>
> What I (and believe Kent) want is a guarantee that it won't signal an
> error; if nothing else works COMPILE will simply apply #'IDENTITY to
> the symbol's function.
If this is the position people really want to adopt, I think we ought
to flush the COMPILED-FUNCTION type. I can't imagine it would be
very useful in declarations if we always allow COMPILE to be a no-op
and never require it to return a COMPILED-FUNCTION.
While I would expect that a COMPILE which resulted in IDENTITY would
not necessarily make the function a COMPILED-FUNCTION, I have absolutely no
objections to flushing the type.
I still think that the minimum requirements for compilation specified in
the proposal should apply to COMPILE-FILE, regardless of what happens
to COMPILE and COMPILED-FUNCTION.
I agree. I would also accept a requirement that COMPILE could cause a
function to become a COMPILED-FUNCTION iff it met the minimum
requirements in the proposal. Note this could still mean, for a
function in which a prepass caused no changes, that IDENTITY could
cause the function to become a COMPILED-FUNCTION. While this may
sound a bit absurd it's consistent with the position we seem to be
adopting that, COMPILE is "macroexpand-completely" in an
interpreted-only implementation.
∂16-Mar-89 1231 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Mar 89 12:31:20 PST
Received: from mist by multimax.encore.com with SMTP (5.61/25-eef)
id AA08012; Thu, 16 Mar 89 15:29:08 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA07524; Thu, 16 Mar 89 15:27:23 EST
Message-Id: <8903162027.AA07524@mist.>
To: Barry Margolin <barmar@FAFNIR.THINK.COM>
Cc: cl-compiler@sail.stanford.edu
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
In-Reply-To: Your message of Thu, 16 Mar 89 15:06:00 -0500.
<19890316200608.9.BARMAR@OCCAM.THINK.COM>
Date: Thu, 16 Mar 89 15:27:21 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Thu, 16 Mar 89 15:06 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Date: Thu, 16 Mar 89 12:31 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Another thing I just thought of is something like:
(when (typep f '(and function (not compiled-function)))
(setq f (compile nil f)))
I don't know what it says. However, I didn't apply COMPILE to a symbol,
I applied it to NIL and a function, which means that the anonymous,
interpreted function should be compiled.
Oops, I misread your example.
Actually, now I'm also a bit confused. Since we passed the
FUNCTION-TYPE proposal, is the second argument to COMPILE supposed to be
a lambda expression or a function? Should I have said (compile nil
(source-code f)) ?
Not if you're interested in the value cell of f instead of the function cell.
∂16-Mar-89 1356 CL-Compiler-mailer Issue SAFE-CODE, version 1
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 13:56:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558883; Thu 16-Mar-89 16:53:42 EST
Date: Thu, 16 Mar 89 16:53 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue SAFE-CODE, version 1
To: Dick Gabriel <RPG@SAIL.Stanford.EDU>, masinter.pa@Xerox.COM
cc: cl-compiler@SAIL.Stanford.EDU, x3j13@SAIL.Stanford.EDU
In-Reply-To: <svXEG@SAIL.Stanford.EDU>,
<890316-070317-3708@Xerox>,
<1avs40@SAIL.Stanford.EDU>,
<19890314214907.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Message-ID: <19890316215335.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Either "nonsafe code" or "code not declared safe" has better connotations
for me than "unsafe code." I don't really want to get too deeply involved
in choosing the terminology here (if I did, I would be on the editorial
committee), I only wanted to point out that the word used in version 1
of the proposal had an unwanted connotation for me.
∂16-Mar-89 1400 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 16 Mar 89 14:00:17 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Thu, 16 Mar 89 16:54:31 EST
Date: Thu, 16 Mar 89 16:55 EST
From: Barry Margolin <barmar@Think.COM>
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
To: Dan L. Pierson <pierson@mist.encore.com>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: <8903162027.AA07524@mist.>
Message-Id: <19890316215500.2.BARMAR@OCCAM.THINK.COM>
Date: Thu, 16 Mar 89 15:27:21 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Thu, 16 Mar 89 15:06 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Date: Thu, 16 Mar 89 12:31 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
Another thing I just thought of is something like:
(when (typep f '(and function (not compiled-function)))
(setq f (compile nil f)))
I don't know what it says. However, I didn't apply COMPILE to a symbol,
I applied it to NIL and a function, which means that the anonymous,
interpreted function should be compiled.
Oops, I misread your example.
Actually, now I'm also a bit confused. Since we passed the
FUNCTION-TYPE proposal, is the second argument to COMPILE supposed to be
a lambda expression or a function? Should I have said (compile nil
(source-code f)) ?
Not if you're interested in the value cell of f instead of the function cell.
Huh? Doesn't (source-code f) return the source lambda expression for
the function in the value cell of F? SOURCE-CODE is just a function, so
how could it access the function cell? By the way, I may be
misremembering the name we gave to the function that returns the
original lambda expression; please correct me if so.
barmar
∂16-Mar-89 1407 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 16 Mar 89 14:07:38 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA08824; Thu, 16 Mar 89 17:04:59 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA07776; Thu, 16 Mar 89 17:03:19 EST
Message-Id: <8903162203.AA07776@mist.>
To: Barry Margolin <barmar@Think.COM>
Cc: cl-compiler@sail.stanford.edu
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
In-Reply-To: Your message of Thu, 16 Mar 89 16:55:00 -0500.
Date: Thu, 16 Mar 89 17:03:17 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Actually, now I'm also a bit confused. Since we passed the
FUNCTION-TYPE proposal, is the second argument to COMPILE
supposed to be a lambda expression or a function? Should I
have said (compile nil (source-code f)) ?
Not if you're interested in the value cell of f instead of the
function cell.
Huh? Doesn't (source-code f) return the source lambda expression for
the function in the value cell of F? SOURCE-CODE is just a function, so
how could it access the function cell? By the way, I may be
misremembering the name we gave to the function that returns the
original lambda expression; please correct me if so.
Arg, I must be asleep today. Of course it does. However I believe
that COMPILE wants a function not a source lambda expression.
∂16-Mar-89 1417 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 16 Mar 89 14:17:08 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA09686; Thu, 16 Mar 89 15:10:51 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA06119; Thu, 16 Mar 89 15:10:49 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903162210.AA06119@defun.utah.edu>
Date: Thu, 16 Mar 89 15:10:47 MST
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
To: Dan L. Pierson <pierson@mist.encore.com>
Cc: Barry Margolin <barmar@Think.COM>, cl-compiler@sail.stanford.edu
In-Reply-To: Dan L. Pierson <pierson@mist.encore.com>, Thu, 16 Mar 89 17:03:17 EST
> Arg, I must be asleep today. Of course it does. However I believe
> that COMPILE wants a function not a source lambda expression.
Issue COMPILE-ARGUMENT-PROBLEMS said it would take either. If it gets
a lambda expression, it'll coerce it to a function.
-Sandra
-------
∂16-Mar-89 1443 CL-Compiler-mailer Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 16 Mar 89 14:43:02 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 558959; Thu 16-Mar-89 17:39:16 EST
Date: Thu, 16 Mar 89 17:39 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue COMPILED-FUNCTION-REQUIREMENTS, version 4
To: Barry Margolin <barmar@FAFNIR.THINK.COM>
cc: masinter.pa@xerox.com, cl-compiler@sail.stanford.edu, X3J13@sail.stanford.edu
In-Reply-To: <19890316173142.7.BARMAR@OCCAM.THINK.COM>
Message-ID: <19890316223916.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Thu, 16 Mar 89 12:31 EST
From: Barry Margolin <barmar@FAFNIR.THINK.COM>
I'll just reiterate something I said at one of the meetings. One
portable use I can think of for the COMPILED-FUNCTION type is as a
declaration to allow compiler optimization. If a function knows (or
requires) that a parameter is a compiled function it can declare that
and the implementation may be able to optimize the FUNCALL better.
But as someone said the last time this suggestion was brought up, if
there is no portable meaning of the COMPILED-FUNCTION type and no
portable way to create an object of that type, no useful correct program
can contain this declaration.
Another thing I just thought of is something like:
(when (typep f '(and function (not compiled-function)))
(setq f (compile nil f)))
This doesn't actually work because COMPILE isn't required to accept
lexical closures
You just glimpsed the tip of the iceberg.
∂17-Mar-89 1019 CL-Compiler-mailer issue CONSTANT-FUNCTION-COMPILATION
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Mar 89 10:19:09 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA04848; Fri, 17 Mar 89 11:16:55 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA06877; Fri, 17 Mar 89 11:16:47 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903171816.AA06877@defun.utah.edu>
Date: Fri, 17 Mar 89 11:16:46 MST
Subject: issue CONSTANT-FUNCTION-COMPILATION
To: cperdue@sun.com, rpg@lucid.com, moon@stony-brook.scrc.symbolics.com
Cc: cl-compiler@sail.stanford.edu
Moon has suggested that we split off the issue of compiling constant
functions from issue CONSTANT-COMPILABLE-TYPES and call it
CONSTANT-FUNCTION-COMPILATION. This would allow us to have real
proposals written down in advance instead of trying to compose
amendments on the fly at the meeting (which rarely seems to work out
very well), and keep the arguments over this from bogging down the
rest of issue CONSTANT-COMPILABLE-TYPES, which appears to be
noncontroversial.
The issue is not only whether functions are dumpable, but if they are,
how COMPILE-FILE and LOAD arrange for the function to be
reconstructed. If we can't arrive at a good definition of what
"similar as constants" means for functions, I contend we must leave
the entire question of their dumpability unspecified.
The current language from issue CONSTANT-COMPILABLE-TYPES says that
two (non-compiled, non-closed) functions are similar as constants if
their SOURCE-LAMBDA-EXPRESSIONs are similar as constants. I assume
this was a typo for FUNCTION-LAMBDA-EXPRESSIONs, except that
FUNCTION-LAMBDA-EXPRESSION is always permitted to return NIL if it
can't figure out what the original source code looked like. My
feeling is that this definition of "similar as constants" is
unacceptable because of this.
So, if any of you have some specific language to propose here,
speak up. Otherwise I think we have no choice but to say that
constant functions are not supported.
-Sandra
-------
∂17-Mar-89 1047 CL-Compiler-mailer Re: issue CONSTANT-FUNCTION-COMPILATION
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 10:47:41 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA10182; Fri, 17 Mar 89 10:48:14 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.0)
id AA18058; Fri, 17 Mar 89 10:44:19 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA06760; Fri, 17 Mar 89 10:47:53 PST
Date: Fri, 17 Mar 89 10:47:53 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903171847.AA06760@clam.sun.com>
To: cperdue@Sun.COM, moon@stony-brook.scrc.symbolics.com, rpg@lucid.com,
sandra%defun@cs.utah.edu
Subject: Re: issue CONSTANT-FUNCTION-COMPILATION
Cc: cl-compiler@sail.stanford.edu
> The current language from issue CONSTANT-COMPILABLE-TYPES says that
> two (non-compiled, non-closed) functions are similar as constants if
> their SOURCE-LAMBDA-EXPRESSIONs are similar as constants. I assume
> this was a typo for FUNCTION-LAMBDA-EXPRESSIONs,
Yes.
> except that
> FUNCTION-LAMBDA-EXPRESSION is always permitted to return NIL if it
> can't figure out what the original source code looked like.
So both must be non-NIL.
> My
> feeling is that this definition of "similar as constants" is
> unacceptable because of this.
Yes, please fix.
As long as the langauge of the current proposal can be fixed,
I would prefer to fix it. If we wish to split off an issue
on compiling constant functions, it would be appropriate for
that to amend CONSTANT-COMPILABLE-TYPES. Likewise it is very
easy to amend the current proposal to remove support for constant
functions. Their status would become like the status of streams,
where an implementation may choose to support function constants,
but is not required to do so.
-Cris
∂17-Mar-89 1105 CL-Compiler-mailer Re: issue CONSTANT-FUNCTION-COMPILATION
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Mar 89 11:04:13 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA08374; Fri, 17 Mar 89 12:00:25 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA06917; Fri, 17 Mar 89 12:00:18 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903171900.AA06917@defun.utah.edu>
Date: Fri, 17 Mar 89 12:00:17 MST
Subject: Re: issue CONSTANT-FUNCTION-COMPILATION
To: cperdue@Sun.COM (Cris Perdue)
Cc: moon@stony-brook.scrc.symbolics.com, rpg@lucid.com,
cl-compiler@sail.stanford.edu
In-Reply-To: cperdue@Sun.COM (Cris Perdue), Fri, 17 Mar 89 10:47:53 PST
> Date: Fri, 17 Mar 89 10:47:53 PST
> From: cperdue@Sun.COM (Cris Perdue)
>
> > except that
> > FUNCTION-LAMBDA-EXPRESSION is always permitted to return NIL if it
> > can't figure out what the original source code looked like.
>
> So both must be non-NIL.
>
> > My
> > feeling is that this definition of "similar as constants" is
> > unacceptable because of this.
>
> Yes, please fix.
Let me get this straight. In addition to the requirement that the
function not be compiled and not be closed over any variables, you would
like to add an additional requirement that FUNCTION-LAMBDA-EXPRESSION
for that function not return NIL?
There is still a problem with the informal nature of your first two
requirements. Could we use the second value returned from
FUNCTION-LAMBDA-EXPRESSION for testing the second requirement?
If we retain the COMPILED-FUNCTION type, the problem with
detecting that a function is compiled is taken care of, but is there
any reason why we couldn't dispense with this? If you have the lambda
expression available and that is how "similarity as a constant" is
defined, it shouldn't matter whether the function is compiled or not.
Aside from the problems of specification, I am still wondering why,
since there is no portable way to construct a function which is
guaranteed to meet these requirements, we should bother to specify a
portable behavior for what happens when they are satisfied.
-Sandra
-------
∂17-Mar-89 1225 CL-Compiler-mailer Issue: DEFINE-OPTIMIZER (Version 2)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:25:46 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA00773g; Wed, 15 Mar 89 10:41:07 PST
Received: by challenger id AA12228g; Wed, 15 Mar 89 10:34:58 PST
Date: Wed, 15 Mar 89 10:34:58 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903151834.AA12228@challenger>
To: cl-compiler@sail.stanford.edu
Subject: Issue: DEFINE-OPTIMIZER (Version 2)
I oppose this proposal. First, optimization is rarely something that
can be done portably. Using a name like define-optimizer gives the
impression that something will be done more optimally, and maybe it
won't.
Second, it appears that this functionality is isomorphic to macros,
except possibly macros that are only in effect during compilation.
Third, it seems to solve a problem that is addressed by all the various
abstraction mechanisms around already.
Fourth, it is part of a trend I will call ``featherbedding'', which I
will use in my messages to refer to adding comfortable features to
Common Lisp that are redundant or not strictly necessary.
-rpg-
∂17-Mar-89 1251 CL-Compiler-mailer Re: issue QUOTE-SEMANTICS, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:51:01 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA12581; Fri, 17 Mar 89 13:48:50 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA07042; Fri, 17 Mar 89 13:48:45 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903172048.AA07042@defun.utah.edu>
Date: Fri, 17 Mar 89 13:48:43 MST
Subject: Re: issue QUOTE-SEMANTICS, version 2
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 14 Mar 89 19:48 EST
> Date: Tue, 14 Mar 89 19:48 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> I can't support either of the other two proposals because they use
> the words "copying" and "coalescing" without defining their meaning.
"Copying" means making an equivalent object that is similar as a
constant, but not necessarily EQL, to the original.
I now have a question of my own about how proposal
COPYING-ALLOWED-BUT-NO-CONSTRAINTS interacts with issue
CONSTANT-COMPILABLE-TYPES. Maybe somebody who supports this
issue can help clarify this.
On types where the notion of "similar as a constant" is left
unspecified (for example, readtables), do you want this proposal to
mean that copying is entirely forbidden, or that if the implementation
has defined some behavior for "similar as a constant" on that type,
that it can go ahead and copy?
If copying is entirely forbidden in such a case, the implementation
cost for this proposal will be just as high as for proposal NO-COPYING.
-Sandra
-------
∂17-Mar-89 1251 CL-Compiler-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:51:13 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 559802; Fri 17-Mar-89 15:48:20 EST
Date: Fri, 17 Mar 89 15:48 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: Eric Benson <eb@lucid.com>
cc: cl-compiler@sail.stanford.edu, x3j13@sail.stanford.edu
In-Reply-To: <8903152040.AA00297@blacksox>
Message-ID: <19890317204812.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 15 Mar 89 12:40:06 PST
From: Eric Benson <eb@lucid.com>
Date: Tue, 14 Mar 89 18:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
of a MACROLET special form, instead it should be a list of lists (name
function).
A small point: Shouldn't this be an a-list of the form
(name . function) instead of a list of lists?
Oh, I keep forgetting that some people have to worry about the efficiency
of conses versus lists. I don't care which it is.
∂17-Mar-89 1223 X3J13-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:23:14 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA00913g; Wed, 15 Mar 89 12:36:51 PST
Received: by blacksox id AA00297g; Wed, 15 Mar 89 12:40:06 PST
Date: Wed, 15 Mar 89 12:40:06 PST
From: Eric Benson <eb@lucid.com>
Message-Id: <8903152040.AA00297@blacksox>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-compiler@sail.stanford.edu, x3j13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 14 Mar 89 18:41 EST <19890314234118.3.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Date: Tue, 14 Mar 89 18:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
This looks good so far. A few comments that might help you
along with the draft:
...
The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
of a MACROLET special form, instead it should be a list of lists (name
function). That is, the expander functions should be supplied in the
form of functions rather than in the form of the source text used by
MACROLET. Your rationale argues against this but I strongly believe
that the rationale is wrong. I wouldn't mind seeing the parsing portion
of MACROLET made available as a separate function.
A small point: Shouldn't this be an a-list of the form
(name . function) instead of a list of lists?
∂17-Mar-89 1223 X3J13-mailer issue SAFE-CODE, version 1
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 17 Mar 89 12:22:54 PST
Received: from challenger ([192.9.200.17]) by heavens-gate.lucid.com id AA01090g; Wed, 15 Mar 89 14:31:11 PST
Received: by challenger id AA12754g; Wed, 15 Mar 89 14:25:03 PST
Date: Wed, 15 Mar 89 14:25:03 PST
From: Richard P. Gabriel <rpg@lucid.com>
Message-Id: <8903152225.AA12754@challenger>
To: cl-compiler@sail.stanford.edu, x3j13@sail.stanford.edu
Subject: issue SAFE-CODE, version 1
According to my understanding of the dictionary definitions,
``unsafe'' means primarily ``the opposite or reversal of `safe' '' and
secondarily ``not safe.'' This coincides with Moon's reading.
Therefore, I propose we use the term ``nonsafe'' which clearly means
``not safe.'' This, coupled with the already very explicit definition
of ``unsafe,'' which explains that unsafe code might actually be safe,
should take care of his objection.
-rpg-
∂17-Mar-89 1350 CL-Compiler-mailer Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE
Received: from RELAY.CS.NET by SAIL.Stanford.EDU with TCP; 17 Mar 89 13:50:24 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab27291; 17 Mar 89 15:08 EST
Received: from draper.com by RELAY.CS.NET id aa26896; 17 Mar 89 15:03 EST
Date: Fri, 17 Mar 89 08:07 EST
From: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Subject: Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE
To: cl-compiler@SAIL.STANFORD.EDU
X-VMS-To: CL-COMPILER,SEB1525
>From: David N Gray <Gray@dsg.csc.ti.COM>
>Subject: Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE
>To: "Steve Bacher (Batchman)" <SEB1525@DRAPER.COM>
>Cc: cl-compiler@sail.stanford.EDU
>
>> ... It makes me wonder whether we
>> > should just permit top-level DECLAREs, but then _it_ would need special
>> > handling by the compiler since a macro definition would confuse the
>> > semantics of local declarations, so you don't win.
>>
>> I don't understand the last sentence. What kind of macro definition?
>> Can you give an example?
>
>I just meant that we don't want to define DECLARE as a macro, and that
>having a special form that is treated specially by the compiler at top
>level doesn't seen any better than a function that is treated specially.
Well, aren't PROGN and EVAL-WHEN special forms that are treated specially
by the compiler? Better a special form than a function, no?
∂17-Mar-89 1352 CL-Compiler-mailer Re: issue CONSTANT-FUNCTION-COMPILATION
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 13:51:50 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA14890; Fri, 17 Mar 89 13:52:21 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA26492; Fri, 17 Mar 89 13:48:29 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA07023; Fri, 17 Mar 89 13:52:05 PST
Date: Fri, 17 Mar 89 13:52:05 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903172152.AA07023@clam.sun.com>
To: sandra%defun@cs.utah.edu
Subject: Re: issue CONSTANT-FUNCTION-COMPILATION
Cc: cl-compiler@sail.stanford.edu, moon@stony-brook.scrc.symbolics.com,
rpg@lucid.com
Sorry, my mistake. Using FUNCTION-LAMBDA-EXPRESSION
is no good at all.
∂17-Mar-89 1356 CL-Compiler-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 13:54:27 PST
Received: from fafnir.think.com by Think.COM; Fri, 17 Mar 89 16:48:54 EST
Return-Path: <gls@Think.COM>
Received: from verdi.think.com by fafnir.think.com; Fri, 17 Mar 89 16:50:04 EST
Received: by verdi.think.com; Fri, 17 Mar 89 16:46:51 EST
Date: Fri, 17 Mar 89 16:46:51 EST
From: Guy Steele <gls@Think.COM>
Message-Id: <8903172146.AA09535@verdi.think.com>
To: Moon@stony-brook.scrc.symbolics.com
Cc: eb@lucid.com, cl-compiler@sail.stanford.edu, x3j13@sail.stanford.edu
In-Reply-To: David A. Moon's message of Fri, 17 Mar 89 15:48 EST <19890317204812.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Date: Fri, 17 Mar 89 15:48 EST
From: David A. Moon <Moon@stony-brook.scrc.symbolics.com>
Date: Wed, 15 Mar 89 12:40:06 PST
From: Eric Benson <eb@lucid.com>
Date: Tue, 14 Mar 89 18:41 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
The :MACRO argument to AUGMENT-ENVIRONMENT shouldn't look like the CADR
of a MACROLET special form, instead it should be a list of lists (name
function).
A small point: Shouldn't this be an a-list of the form
(name . function) instead of a list of lists?
Oh, I keep forgetting that some people have to worry about the efficiency
of conses versus lists. I don't care which it is.
Well, don't forget PAIRLIS and ACONS, which make the CONS format
a little easier to use than the LIST format.
[Voice 1: AAAAHHHHH!!! No!!! Not FORMAT!!!]
Calm down; I meant it generically. Make that "organization".
[Voice 2: AUUGUGGHH! Not generics!]
--Guy
∂17-Mar-89 1401 CL-Compiler-mailer Re: issue CONSTANT-FUNCTION-COMPILATION
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Mar 89 14:01:14 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA15114; Fri, 17 Mar 89 14:58:54 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA07201; Fri, 17 Mar 89 14:58:17 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903172158.AA07201@defun.utah.edu>
Date: Fri, 17 Mar 89 14:58:16 MST
Subject: Re: issue CONSTANT-FUNCTION-COMPILATION
To: cperdue@Sun.COM (Cris Perdue)
Cc: cl-compiler@sail.stanford.edu, moon@stony-brook.scrc.symbolics.com,
rpg@lucid.com
In-Reply-To: cperdue@Sun.COM (Cris Perdue), Fri, 17 Mar 89 13:52:05 PST
> Sorry, my mistake. Using FUNCTION-LAMBDA-EXPRESSION
> is no good at all.
Do you have any other ideas? Like I said before, if nobody comes up
with something specific to define how COMPILE-FILE and LOAD
reconstruct functions, I don't see how we can do anything but say that
functions are unsupported in compiled constants.
-Sandra
-------
∂17-Mar-89 1415 CL-Compiler-mailer Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Mar 89 14:15:33 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA15746; Fri, 17 Mar 89 15:13:19 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA07216; Fri, 17 Mar 89 15:13:10 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903172213.AA07216@defun.utah.edu>
Date: Fri, 17 Mar 89 15:13:09 MST
Subject: Re: Issue PROCLAIM-ETC-IN-COMPILE-FILE
To: "Steve Bacher (Batchman)" <SEB1525@draper.com>
Cc: cl-compiler@SAIL.STANFORD.EDU
In-Reply-To: "Steve Bacher (Batchman)" <SEB1525@draper.com>, Fri, 17 Mar 89 08:07 EST
To me, the real problem with having DECLARE be meaningful at top-level
is not that it gets special treatment at compile-time, but that it
gets special treatment at run-time. CLtL explicitly says that "it is
an error to evaluate a declaration", and I think it would be
incredibly ugly for it to be meaningful to evaluate DECLARE in some
cases and have it be an error in others.
I think of DECLARE as being more of a syntactic marker like LAMBDA
than a special form. I suspect that the reason why it is documented
as a special form has more to do with history than anything else. It's
useful so you can signal an error if it appears in the wrong place,
but that's about it.
Trying to get this discussion back along more productive lines, does
anybody have a suggestion for a better name for DEFPROCLAIM? A look at
the thesaurus came up with "announce" as another synonym for declare or
proclaim, but that might be too generic-sounding.
-Sandra
-------
∂17-Mar-89 1558 CL-Compiler-mailer Re: issue QUOTE-SEMANTICS, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 15:58:38 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560066; Fri 17-Mar-89 18:55:56 EST
Date: Fri, 17 Mar 89 18:55 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue QUOTE-SEMANTICS, version 2
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@sail.stanford.edu
In-Reply-To: <8903172048.AA07042@defun.utah.edu>
Message-ID: <19890317235548.9.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Fri, 17 Mar 89 13:48:43 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Date: Tue, 14 Mar 89 19:48 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> I can't support either of the other two proposals because they use
> the words "copying" and "coalescing" without defining their meaning.
"Copying" means making an equivalent object that is similar as a
constant, but not necessarily EQL, to the original.
OK, but the proposal needs to be updated to say that, since I want
to base my vote only on what proposals actually say.
I now have a question of my own about how proposal
COPYING-ALLOWED-BUT-NO-CONSTRAINTS interacts with issue
CONSTANT-COMPILABLE-TYPES. Maybe somebody who supports this
issue can help clarify this.
On types where the notion of "similar as a constant" is left
unspecified (for example, readtables), do you want this proposal to
mean that copying is entirely forbidden, or that if the implementation
has defined some behavior for "similar as a constant" on that type,
that it can go ahead and copy?
I don't think I'm the one you were expecting a reply from, but if I
have to guess, I think it's the latter. If an implementation is allowed
to extend "similar as a constant", then copying is consistent with the
definition of "similar as a constant" actually in force in that
implementation, not with the book definition.
If copying is entirely forbidden in such a case, the implementation
cost for this proposal will be just as high as for proposal NO-COPYING.
Does this mean that as long as there is one data type for which copying
is forbidden, perhaps some user-defined data type, there is no implementation
advantage of COPYING-ALLOWED-BUT-NO-CONSTRAINTS over NO-COPYING?
If so, that would seem to knock COPYING-ALLOWED-BUT-NO-CONSTRAINTS
pretty completely out of the running.
∂17-Mar-89 1712 CL-Compiler-mailer Re: issue QUOTE-SEMANTICS, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Mar 89 17:11:56 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA21554; Fri, 17 Mar 89 18:09:42 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA07417; Fri, 17 Mar 89 18:09:40 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903180109.AA07417@defun.utah.edu>
Date: Fri, 17 Mar 89 18:09:38 MST
Subject: Re: issue QUOTE-SEMANTICS, version 2
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Fri, 17 Mar 89 18:55 EST
> Date: Fri, 17 Mar 89 18:55 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> If an implementation is allowed
> to extend "similar as a constant", then copying is consistent with the
> definition of "similar as a constant" actually in force in that
> implementation, not with the book definition.
That has been my interpretation all along, too, but as I was looking over
the proposal to incorporate your suggested changes, I realized that it
didn't explicitly say that anywhere.
> If copying is entirely forbidden in such a case, the implementation
> cost for this proposal will be just as high as for proposal NO-COPYING.
>
> Does this mean that as long as there is one data type for which copying
> is forbidden, perhaps some user-defined data type, there is no implementation
> advantage of COPYING-ALLOWED-BUT-NO-CONSTRAINTS over NO-COPYING?
> If so, that would seem to knock COPYING-ALLOWED-BUT-NO-CONSTRAINTS
> pretty completely out of the running.
There would be an implementation advantage in that you could still
copy constants into some part of memory that is not GC'ed, for
example. That could be beneficial from a memory-management point of
view. But yes, those implementations that would have problems with
proposal NO-COPYING would have exactly the same problems with
COPYING-ALLOWED-BUT-NO-CONSTRAINTS unless they define what "similar as
a constant" means for all possible data types.
Incidentally, this afternoon I discussed this issue in some detail
with Leigh Stoller, who is the chief compiler hacker for Utah Common
Lisp. UCL now implements COMPILE in a manner similar to KCL -- it
creates a temporary FASL file which it then LOADs in the usual way,
and the GC assumes that compiled constants never need to be relocated
or scanned. Leigh says he thinks UCL will probably never be changed
to implement COMPILE any other way, regardless of the outcome of this
issue. Partly it's a matter of the work involved, but it's also
because he feels pretty strongly that having different conformance
requirements for compiled and interpreted code would just encourage
people to write programs that would break when compiled. I mentioned
the alternative of just implementing COMPILE as a simple-minded code
walker and not having it produce a "real" compiled function at all,
but he said he thought that would be a giant step backwards. UCL will
probably never be a conforming implementation for other reasons, but
on this issue it looks like they'd rather be deliberately nonconforming
than do something which Leigh described as being "really dumb".
-Sandra
-------
∂17-Mar-89 1729 CL-Compiler-mailer cl-compiler subcommittee meeting & agenda
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 17 Mar 89 17:28:51 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA21676; Fri, 17 Mar 89 18:26:36 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA07442; Fri, 17 Mar 89 18:26:34 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903180126.AA07442@defun.utah.edu>
Date: Fri, 17 Mar 89 18:26:33 MST
Subject: cl-compiler subcommittee meeting & agenda
To: cl-compiler@sail.stanford.edu
It looks like I am also going to get sucked into the editorial
committee meeting Monday night. How would people feel about meeting
for an hour or so Tuesday morning, before the official meeting starts
(scheduled for 9:00)? If anybody has serious problems with being awake
at that time of morning we could try to arrange something Tuesday
evening, but my guess is it'll be harder to find a place to meet then.
I've heard from Jan again that the agenda has been changed back to
what it was originally. We're scheduled for Wednesday afternoon
again.
-Sandra
-------
∂17-Mar-89 2254 CL-Cleanup-mailer Re: Issue: LOAD-OBJECTS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 17 Mar 89 22:54:01 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 560294; Sat 18-Mar-89 01:50:31 EST
Date: Sat, 18 Mar 89 01:50 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Richard P. Gabriel <rpg@lucid.com>
cc: CL-Cleanup@sail.stanford.edu, CL-Compiler@sail.stanford.edu, Common-Lisp-Object-System@sail.stanford.edu
In-Reply-To: <8903120142.AA00878@defun.utah.edu>
Message-ID: <19890318065022.2.MOON@EUPHRATES.SCRC.Symbolics.COM>
There are a couple of small changes that seem warranted:
MAKE-LOAD-FORM-USING-SLOTS is too easy to confuse with
SLOT-VALUE-USING-CLASS. MAKE-LOAD-FORM-FROM-SLOTS is better,
except for form/from dyslexia. MAKE-LOAD-FORM-FOR-SLOTS ?
Maybe there should be a SIMILAR-AS-CONSTANTS generic function
for the benefit of CONSTANT-COLLAPSING. In the absence of that
we're just using EQ.
On the subject of this proposed alternative:
Date: Sat, 11 Mar 89 18:42:56 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Have two generic functions, not one. The first would get called by
compile-file and it would return a list of components (or whatever)
that are required to reconstruct the object. The compiler would dump
this list of objects in its usual way. The loader would apply the
second generic function to this list to reconstruct the object.
This is exactly the way I did the first implementation of this idea,
back in about 1978. It didn't work very well, basically for two reasons.
One is that representing information in the form of lists is pretty
impoverished and it's very easy to get the list the wrong length or
out of order; it's also more difficult than it should be to make
upward-compatible changes, because the new format always has to be
a superset of the old format. Forms are more general. You can make
upward-compatible changes by inventing a new function name and keeping
the old function name around forever with the old semantics; this also
ensures an undefined-function error if the new format is loaded into
the old system.
The second reason is more serious. The way you propose cannot be nicely
extended to deal with circular structures, because it fails to separate
object creation from object initialization. The second generic function
does both operations. My application used circular structures
extensively and had a fairly horrible kludge for them, involving standin
objects that were replaced with the correct objects later in loading;
this was fragile and permeated the reconstruction methods, all the worst
characteristics for this kind of thing.
On the subject of forms versus functions as the interface, I think
David Gray has expressed very well the reasons why that is not
practical, at least at Common Lisp's present stage of development.
I've read all the mail on the subject, but I stand by LOAD-OBJECTS
version 3. There may be more thought behind this proposal than is
apparent at first glance.
∂17-Mar-89 2338 CL-Compiler-mailer Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 17 Mar 89 23:38:32 PST
Received: from Cabernet.ms by ArpaGateway.ms ; 17 MAR 89 23:35:49 PST
Date: 17 Mar 89 23:34 PST
From: masinter.pa@Xerox.COM
Subject: Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
In-reply-to: sandra%defun@cs.utah.edu (Sandra J Loosemore)'s message of
Mon, 13 Mar 89 17:19:48 -0700
To: cl-compiler@sail.stanford.edu
cc: masinter.pa@Xerox.COM
Message-ID: <890317-233549-3549@Xerox>
I think VARIABLE-TYPE is too "generic" a name for what you use it for. Its
maybe VARIABLE-TYPE-SPECIFIER or even VARIABLE-TYPE-DECLARATION.
VARIABLE-KIND is probably also too generic, although "kind" isn't as
overloaded as "TYPE".
Perhaps VARIABLE-BINDING-KIND or even VARIABLE-BINDING-TYPE.
The problems with VARIABLE-KIND and VARIABLE-TYPE is that there are many
different categorizations that can apply to a VARIABLE, and KIND and TYPE
don't identify the dimensions.
(VARIABLE-TYPE 'this-is-a-variable-with-a-bad-name)
=> :long
(VARIABLE-TYPE '|``''W@#!|)
=> :unreadable
etc.
∂18-Mar-89 0655 CL-Compiler-mailer Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 18 Mar 89 06:55:22 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA29761; Sat, 18 Mar 89 07:53:10 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA08047; Sat, 18 Mar 89 07:53:07 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903181453.AA08047@defun.utah.edu>
Date: Sat, 18 Mar 89 07:53:04 MST
Subject: Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: masinter.pa@Xerox.COM
Cc: cl-compiler@sail.stanford.edu, masinter.pa@Xerox.COM
In-Reply-To: masinter.pa@Xerox.COM, 17 Mar 89 23:34 PST
Thanks -- those are good suggestions. I think we'd like to keep the
names of the FUNCTION-xxx functions similar to the VARIABLE-xxx ones,
too.
How about
VARIABLE-DECLARED-TYPE FUNCTION-DECLARED-TYPE
VARIABLE-BINDING-KIND FUNCTION-BINDING-KIND
-Sandra
-------
∂18-Mar-89 0909 CL-Compiler-mailer issue SYNTACTIC-ENVIRONMENT-ACCESS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 18 Mar 89 09:09:08 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA00948; Sat, 18 Mar 89 10:06:44 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA08173; Sat, 18 Mar 89 10:06:18 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903181706.AA08173@defun.utah.edu>
Date: Sat, 18 Mar 89 10:06:16 MST
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS
To: cl-compiler@sail.stanford.edu
Cc: moon@stony-brook.scrc.symbolics.com, masinter.pa@xerox.com
Let's try to reach closure on this issue so I can get another draft
circulated before the meeting. Here is a summary of what I think has
happened since the last version was mailed out.
* Standardizing remote environments at this time would probably be the
wrong thing, since their use in CLOS is being reconsidered. We should
probably discard proposals MEDIUM and LARGE and work with SMALL only
for now.
* VARIABLE-KIND should return the same second value as FUNCTION-KIND.
* Clarify that VARIABLE-TYPE is permitted to "upgrade" types.
* Change the format of the :MACRO argument to AUGMENT-ENVIRONMENT and
add a function PARSE-MACRO.
* The names of the functions VARIABLE-TYPE and VARIABLE-KIND are too
"generic" and ought to be changed.
The remaining issue is still troublesome:
* We need some way to access other kinds of declarations, particularly
INLINE/NOTINLINE, IGNORE, and OPTIMIZE.
I see three possible solutions to this:
(1) Add a DECLARATION function:
DECLARATION decl-type name &optional env [Function]
(2) Add individual accessor functions for each declaration:
VARIABLE-DECLARED-IGNORE name &optional env [Function]
FUNCTION-DECLARED-INLINE name &optional env [Function]
OPTIMIZE-LEVEL quality &optional env [Function]
(3) Merge VARIABLE-KIND, VARIABLE-TYPE, and VARIABLE-DECLARED-IGNORE
into a single function, VARIABLE-INFORMATION, that returns
four values:
- what the current proposal says VARIABLE-KIND returns.
- a local-p boolean to indicate whether the binding is local or global
- a type specifier as for VARIABLE-TYPE
- an ignore-p boolean to indicate whether the variable has been
declared IGNORE.
Similarly, FUNCTION-KIND, FUNCTION-FTYPE, and FUNCTION-DECLARED-INLINE
would be merged into FUNCTION-INFORMATION.
Add the OPTIMIZE-LEVEL function.
Personally, I like option #3 best. How about the rest of you?
-Sandra
-------
∂18-Mar-89 1608 CL-Compiler-mailer **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 18 Mar 89 16:08:49 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Sat, 18 Mar 89 18:07:36 CST id AA02568 for cl-compiler@sail.stanford.edu
Posted-Date: Sat, 18 Mar 89 18:05:47 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA20237; Sat, 18 Mar 89 18:05:47 CST
Date: Sat, 18 Mar 89 18:05:47 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903190005.AA20237@pavo.src.honeywell.com>
To: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 13 Mar 89 17:19:48 -0700 <8903140019.AA02631@defun.utah.edu>
Subject: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
I initially was going to ask if ENVIRONMENT-REMOTE-P shouldn't be called
REMOTE-ENVIRONEMENT-P
ENVIRONMENT-REMOTE-P env [Function]
Returns true if ENV is a remote environment, false otherwise.
Shouldn't ENVIRONMENT-REMOTE-P be called REMOTE-ENVIRONEMENT-P? Is it
required that the argument be an environment?
On a related note, there is no requirement that environments have a type
specifier (and consequently the disjointedness of that type), nor a
predicate ENVIRONMENT-P. I assume this is because it would be nice if it
were possible to implement environments as alists. I guess I don't have an
objection to that, but the possibility of the type not being disjoint
from any other CL type should be mentioned. If this is already stated in
CLtL, then please ignore this comment (I'll check when I get to work).
∂19-Mar-89 1346 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 19 Mar 89 13:46:10 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA19051; Sun, 19 Mar 89 13:46:49 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA25776; Sun, 19 Mar 89 13:43:00 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA12450; Sun, 19 Mar 89 13:46:38 PST
Date: Sun, 19 Mar 89 13:46:38 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903192146.AA12450@clam.sun.com>
To: cl-compiler@sail.stanford.edu, sandra%defun@cs.utah.edu
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
Cc: masinter.pa@xerox.com, moon@stony-brook.scrc.symbolics.com
> * We need some way to access other kinds of declarations, particularly
> INLINE/NOTINLINE, IGNORE, and OPTIMIZE.
>
> I see three possible solutions to this:
>
> (1) Add a DECLARATION function:
>
> (2) Add individual accessor functions for each declaration:
>
> (3) Merge VARIABLE-KIND, VARIABLE-TYPE, and VARIABLE-DECLARED-IGNORE
> into a single function, VARIABLE-INFORMATION, that returns
> four values:
The language permits implementation-dependent declaration types,
so I think we want to define accessors that can also be extended
by implementations.
Solution (2) already has the appearance of suffering from
profusion of names.
(1) is very general, but may require multiple requests to get
the information of interest.
(3) gets a predefined set of information in one operation.
Given what I understand of this issue, I somewhat prefer (1), especially
because it is so easily extended.
(3) looks acceptable also, but I think we would want to explicitly
permit implementations to add more return values to return information
about implementation-dependent declarations.
∂19-Mar-89 1655 CL-Compiler-mailer issue CONSTANT-COMPILABLE-TYPES, version 8
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 19 Mar 89 16:55:14 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Sun, 19 Mar 89 18:21:09 CST id AA13098 for cl-compiler@sail.stanford.edu
Posted-Date: Sun, 19 Mar 89 18:19:20 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA21032; Sun, 19 Mar 89 18:19:20 CST
Date: Sun, 19 Mar 89 18:19:20 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903200019.AA21032@pavo.src.honeywell.com>
To: cl-compiler@sail.stanford.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 13 Mar 89 09:12:49 -0700 <8903131612.AA02083@defun.utah.edu>
Subject: issue CONSTANT-COMPILABLE-TYPES, version 8
Some types such as streams are not supported in constants. Put
another way, an object containing one of these is not considered
similar as a constant to any other object. Some implementations may
support them and define how they are treated. For any object that
appears in a constant, but is not supported by the language as part of
a constant, the behavior of the compiler is unspecified; either the
the compiler and/or loader will handle that constant (in an
implementation-dependent manner) or the compiler will detect the
situation and signal an error.
The part about "...is unspecified; either..." is somewhat confusing to me.
Is the intent of this to say that it will either "work", or an error will
be signalled at compile time? I.e. it is illegal for the system to signal
an error at load time, or for the error to go unsignalled? The
unspecified, harmless, undefined stuff is rapidly becomming a tar pit...
Number
If either of the two objects is a number, both must be of the same
type and must represent the same mathematical value.
For Number and Character is there some reason why you don't use CL
functions in the definitions of similar as constants, e.g. "Numbers are
similar as constants iff they are EQL"?
Consider a hash table as an unordered set of key and
value pairs. Two hash tables are similar as constants
exactly if there is a one-to-one correspondence between
the key and value pairs of each and a one-to-one
correspondence between the uninterned symbols ...
Where did the symbols come from?
∂19-Mar-89 2019 CL-Compiler-mailer issue LOAD-TIME-EVAL, version 11
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 19 Mar 89 20:19:21 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Sun, 19 Mar 89 22:20:07 CST id AA14552 for cl-compiler@sail.stanford.edu
Posted-Date: Sun, 19 Mar 89 22:18:17 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA21128; Sun, 19 Mar 89 22:18:17 CST
Date: Sun, 19 Mar 89 22:18:17 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903200418.AA21128@pavo.src.honeywell.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: David A. Moon's message of Tue, 14 Mar 89 20:02 EST <19890315010205.8.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: issue LOAD-TIME-EVAL, version 11
| If the same (compared with EQ) list (LOAD-TIME-VALUE <form>) is
| evaluated or compiled more than once, it is unspecified whether <form>
| is evaluated only once or is evaluated more than once. This can
I find myself strongly opposed to **3. Given:
(defun foo ()
(macrolet ((bar () '(load-time-value (make-instance 'mumble))))
(list (bar) (bar))))
(defun foo1 ()
(list (load-time-value (make-instance 'mumble))
(load-time-value (make-instance 'mumble))))
I find that I would have a hard time explaining to someone why the value of
foo can be a list of two objects EQ to one another, but that foo1 is
gauranteed to return non EQ objects. After they grasp that, the next
question is bound to be "Does that mean that in the following example N may
only be incremented by 1?"
(defun baz (N)
(macrolet ((bar () '(incf n)))
(bar)
(bar)))
I've had a hard enough time explaining why
(let ((x '(a b c)))
(eq (eval `(quote ,x))
(eval `(quote ,x))))
should be permitted to return NIL. My argument has been something like
"The identity of the conses that make up a program shouldn't be significant
to the value of the program". Proposal **3 sort of shoots down that
argument.
I appologize for not being able to put this in the form of a rational
argument, perhaps I will by the meeting. The added semantic complexity
introduced by **3 just doesn't seam worth it.
∂20-Mar-89 0805 CL-Compiler-mailer Re: issue LOAD-TIME-EVAL, version 11
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Mar 89 08:04:52 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA10755; Mon, 20 Mar 89 09:04:10 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA09790; Mon, 20 Mar 89 09:03:46 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903201603.AA09790@defun.utah.edu>
Date: Mon, 20 Mar 89 09:03:45 MST
Subject: Re: issue LOAD-TIME-EVAL, version 11
To: alarson@src.honeywell.com (Aaron Larson)
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, cl-compiler@sail.stanford.edu
In-Reply-To: alarson@src.honeywell.com (Aaron Larson), Sun, 19 Mar 89 22:18:17 CST
> Date: Sun, 19 Mar 89 22:18:17 CST
> From: alarson@src.honeywell.com (Aaron Larson)
>
> My argument has been something like
> "The identity of the conses that make up a program shouldn't be significant
> to the value of the program". Proposal **3 sort of shoots down that
> argument.
The objection that was raised to proposal **2 was that the notion of
"references" to LOAD-TIME-VALUE forms was not well-defined. The one
example that was raised that bothered me the most was something like
(flet ((foo () (load-time-value (bar))))
(declare (inline foo))
(list (foo) (foo)))
Intuitively, there's only one reference to the LOAD-TIME-VALUE
expression, but if the compiler does the obvious transformation to
code FOO inline, you've suddenly got two references.
Basically, what proposal **3 does is avoid this whole problem by
putting the burden on programmers to be very careful about potential
sharing of LOAD-TIME-VALUE expressions. (It's really only a problem
for ones that are non-read-only.) There are some of us who feel kind
of uncomfortable about this, but it seemed like trying to come up with
a formal definition of what a unique reference to a LOAD-TIME-VALUE
form meant would open up an even bigger can of worms.
-Sandra
-------
∂20-Mar-89 0816 CL-Compiler-mailer Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Mar 89 08:15:52 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA11458; Mon, 20 Mar 89 09:15:44 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA09814; Mon, 20 Mar 89 09:15:42 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903201615.AA09814@defun.utah.edu>
Date: Mon, 20 Mar 89 09:15:40 MST
Subject: Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: alarson@src.honeywell.com (Aaron Larson)
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: alarson@src.honeywell.com (Aaron Larson), Sat, 18 Mar 89 18:05:47 CST
I think there is now a consensus in the compiler committee that the
concept of remote environments is not yet ready to be standardized, so
proposals MEDIUM and LARGE will probably go away in the next
iteration.
As far as I can discover, CLtL doesn't say anything about the
representation of environments, and I don't want this issue to add any
restrictions. One popular representation appears to be as a list of
structures.
-Sandra
-------
∂20-Mar-89 0922 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Mar 89 09:22:09 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA13532; Mon, 20 Mar 89 10:22:04 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA09869; Mon, 20 Mar 89 10:21:48 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903201721.AA09869@defun.utah.edu>
Date: Mon, 20 Mar 89 10:21:47 MST
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
To: cperdue@Sun.COM (Cris Perdue)
Cc: cl-compiler@sail.stanford.edu, masinter.pa@xerox.com,
moon@stony-brook.scrc.symbolics.com
In-Reply-To: cperdue@Sun.COM (Cris Perdue), Sun, 19 Mar 89 13:46:38 PST
The problem I have with option 1 (adding a DECLARATION function to
access declarations) is that declarations don't have a regular syntax,
and that "decl-type" and "name" arguments might not be appropriate for
expressing the syntax of implementation-specific declarations. For
example, several implementations support declarations that control
global attributes (like downward-only closures or suppressing style
warnings) that aren't associated with any "name". Even more peculiar
would be something like the declaration Lucid supports that lets you
say that any objects of a given type really belong to a more specific
type (such as that all numbers will be fixnums).
-Sandra
-------
∂20-Mar-89 1056 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Mar 89 10:56:00 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA18614; Mon, 20 Mar 89 11:55:55 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA09943; Mon, 20 Mar 89 11:55:44 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903201855.AA09943@defun.utah.edu>
Date: Mon, 20 Mar 89 11:55:43 MST
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
To: cperdue@Sun.COM (Cris Perdue)
Cc: cl-compiler@sail.stanford.edu, masinter.pa@xerox.com,
moon@stony-brook.scrc.symbolics.com
In-Reply-To: cperdue@Sun.COM (Cris Perdue), Mon, 20 Mar 89 10:49:15 PST
I think I would rather have implementations provide their own
non-portable accessors for their non-portable declarations, than to
allow VARIABLE-INFORMATION and FUNCTION-INFORMATION to be extended to
return extra values. I don't have really strong feelings about this,
however. Are there any other functions that explicitly allow extra
values to be returned?
-Sandra
-------
∂20-Mar-89 1228 CL-Compiler-mailer Re: cl-compiler subcommittee meeting & agenda
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 20 Mar 89 12:28:21 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA00941; Mon, 20 Mar 89 12:05:25 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA01346; Mon, 20 Mar 89 09:56:58 EST
Message-Id: <8903201456.AA01346@mist.>
To: "sandra%defun@cs.utah.edu"@multimax.encore.com (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu
Subject: Re: cl-compiler subcommittee meeting & agenda
In-Reply-To: Your message of Fri, 17 Mar 89 18:26:33 -0700.
<8903180126.AA07442@defun.utah.edu>
Date: Mon, 20 Mar 89 09:56:55 EST
From: Dan L. Pierson <pierson@mist.encore.com>
It looks like I am also going to get sucked into the editorial
committee meeting Monday night. How would people feel about meeting
for an hour or so Tuesday morning, before the official meeting starts
(scheduled for 9:00)? If anybody has serious problems with being awake
at that time of morning we could try to arrange something Tuesday
evening, but my guess is it'll be harder to find a place to meet then.
I can probably manage to be physically present at an early meeting,
but won't be mentally there. On the other hand, it may not matter
much since I'm not a prime mover on any of the current hot issues.
dan
∂20-Mar-89 1240 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89 12:40:27 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA02507; Mon, 20 Mar 89 11:04:34 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA15128; Mon, 20 Mar 89 11:00:32 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA02685; Mon, 20 Mar 89 11:04:07 PST
Date: Mon, 20 Mar 89 11:04:07 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903201904.AA02685@clam.sun.com>
To: cperdue@Sun.COM, sandra%defun@cs.utah.edu
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
Cc: cl-compiler@sail.stanford.edu, masinter.pa@xerox.com,
moon@stony-brook.scrc.symbolics.com
> I think I would rather have implementations provide their own
> non-portable accessors for their non-portable declarations, than to
> allow VARIABLE-INFORMATION and FUNCTION-INFORMATION to be extended to
> return extra values. I don't have really strong feelings about this,
> however. Are there any other functions that explicitly allow extra
> values to be returned?
I believe Moon has proposed that certain functions be allowed
to return implementation-dependent extra values.
-Cris
∂20-Mar-89 1240 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89 12:38:32 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA02156; Mon, 20 Mar 89 10:49:34 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA14068; Mon, 20 Mar 89 10:45:37 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA02660; Mon, 20 Mar 89 10:49:15 PST
Date: Mon, 20 Mar 89 10:49:15 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903201849.AA02660@clam.sun.com>
To: cperdue@Sun.COM, sandra%defun@cs.utah.edu
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
Cc: cl-compiler@sail.stanford.edu, masinter.pa@xerox.com,
moon@stony-brook.scrc.symbolics.com
Regarding your objections to option 1, it is true that not
all declaration specifiers must affect a particular "name".
What is your attitude toward allowing implementations to extend
the number of return values of VARIABLE-INFORMATION?
It would be unfortunate if we define SYNTACTIC-ENVIRONMENT-ACCESS
but don't make it as general as the declaration facilities
of Common Lisp.
The existence of the "declaration" declaration specifier
(CLtL p160) implies that the set of declaration specifier
names is extensible. On page 161 there is even reference to
declarations "meant for another compiler or program processor",
so declarations could exist for processors that aren't even
compilers.
I would certainly still vote for a proposal that makes it
possible for implementations to return extra values from
VARIABLE-INFORMATION -- and FUNCTION-INFORMATION.
-Cris
∂20-Mar-89 1252 CL-Compiler-mailer issue LOAD-TIME-EVAL, version 11
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 12:51:12 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561221; Mon 20-Mar-89 15:46:26 EST
Date: Mon, 20 Mar 89 15:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue LOAD-TIME-EVAL, version 11
To: Aaron Larson <alarson@src.honeywell.com>
cc: cl-compiler@SAIL.STANFORD.EDU
In-Reply-To: <8903200418.AA21128@pavo.src.honeywell.com>
Message-ID: <19890320204610.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Sun, 19 Mar 89 22:18:17 CST
From: alarson@src.honeywell.com (Aaron Larson)
I find myself strongly opposed to **3.
Read Sandra's answer first.
The problem is that the **2 proposal is not well specified and thus
cannot be implemented, or will require the implementor to make arbitrary
decisions that will probably come out different ways for different
implementations.
Thus I think it's incumbent on anyone who opposes **3 to propose an
alternative, and I think just going back to **2 is not a viable
alternative.
∂20-Mar-89 1315 CL-Compiler-mailer Re: Issue CONSTANT-COMPILABLE-TYPES, version 7
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Mar 89 13:15:09 PST
Received: from aiai.edinburgh.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa08016; 20 Mar 89 19:00 GMT
Date: Mon, 20 Mar 89 19:00:20 GMT
Message-Id: <8080.8903201900@subnode.aiai.ed.ac.uk>
From: Jeff Dalton <jeff%aiai.edinburgh.ac.uk@NSS.Cs.Ucl.AC.UK>
Subject: Re: Issue CONSTANT-COMPILABLE-TYPES, version 7
To: "Richard P. Gabriel" <@sail.stanford.edu:rpg@lucid.com>,
cl-compiler@sail.stanford.edu
In-Reply-To: Richard P. Gabriel's message of Sat, 11 Mar 89 16:09:56 PST
> I guess I pretty strongly object to leaving functions out of the list
> of constants that can appear in compiled code. The part that's
> disturbing is that such non-Lispy things like arrays, hashtables, and
> pathnames get better treatment than functions, the most Lispy part of
> Common Lisp.
I'd like to be able to dump functions, but some Common Lisps will
find it difficult to dump arbitrary compiled functions. Dumping
names would be OK.
Arrays get better treatment because they have convenient printed
representations. I suppose disassemble might be used...
> I wonder how many implementations will be forced to come within an
> inch of the required functionality to implement a first-rate CLOS?
But we don't require that implementations of CLOS be first-rate.
∂20-Mar-89 1315 CL-Compiler-mailer issue COMPILER-VERBOSITY, version 6
Received: from NSS.Cs.Ucl.AC.UK by SAIL.Stanford.EDU with TCP; 20 Mar 89 13:15:01 PST
Received: from maths.bath.ac.uk by NSS.Cs.Ucl.AC.UK via Janet with NIFTP
id aa07991; 20 Mar 89 18:58 GMT
Received: from xenakis by mordell.maths.bath.AC.UK id aa19210;
20 Mar 89 18:59 GMT
To: masinter.pa@xerox.com
CC: cl-compiler@sail.stanford.edu, x3J13@sail.stanford.edu
In-reply-to: masinter.pa@com.xerox's message of 16 Mar 89 05:47 PST <890316-054837-3596@Xerox>
Subject: issue COMPILER-VERBOSITY, version 6
Date: Mon, 20 Mar 89 19:02:07 GMT
From: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
Sender: jpff%maths.bath.ac.uk@NSS.Cs.Ucl.AC.UK
b
∂20-Mar-89 1321 CL-Compiler-mailer issue SYNTACTIC-ENVIRONMENT-ACCESS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 13:20:56 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561266; Mon 20-Mar-89 16:19:11 EST
Date: Mon, 20 Mar 89 16:18 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Cris Perdue <cperdue@Sun.COM>
cc: cl-compiler@SAIL.STANFORD.EDU, masinter.pa@XEROX.COM
In-Reply-To: <8903181706.AA08173@defun.utah.edu>,
<8903192146.AA12450@clam.sun.com>,
<8903201721.AA09869@defun.utah.edu>,
<8903201849.AA02660@clam.sun.com>,
<8903201855.AA09943@defun.utah.edu>,
<8903201904.AA02685@clam.sun.com>
Message-ID: <19890320211858.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I wasn't sure if you expected to hear from me again on this one,
but just in case you did, here are a few brief comments.
Date: Sat, 18 Mar 89 10:06:16 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Let's try to reach closure on this issue so I can get another draft
circulated before the meeting. Here is a summary of what I think has
happened since the last version was mailed out....
All agreed.
The remaining issue is still troublesome:
* We need some way to access other kinds of declarations, particularly
INLINE/NOTINLINE, IGNORE, and OPTIMIZE.
I see three possible solutions to this:
(1) Add a DECLARATION function:
DECLARATION decl-type name &optional env [Function]
(2) Add individual accessor functions for each declaration:
VARIABLE-DECLARED-IGNORE name &optional env [Function]
FUNCTION-DECLARED-INLINE name &optional env [Function]
OPTIMIZE-LEVEL quality &optional env [Function]
(3) Merge VARIABLE-KIND, VARIABLE-TYPE, and VARIABLE-DECLARED-IGNORE
into a single function, VARIABLE-INFORMATION, that returns
four values:
- what the current proposal says VARIABLE-KIND returns.
- a local-p boolean to indicate whether the binding is local or global
- a type specifier as for VARIABLE-TYPE
- an ignore-p boolean to indicate whether the variable has been
declared IGNORE.
Similarly, FUNCTION-KIND, FUNCTION-FTYPE, and FUNCTION-DECLARED-INLINE
would be merged into FUNCTION-INFORMATION.
Add the OPTIMIZE-LEVEL function.
Personally, I like option #3 best. How about the rest of you?
I think the VARIABLE-INFORMATION and FUNCTION-INFORMATION parts of
option #3, combined with some form of option #1 for the other
declarations would suit me best. If we have to, deciding that
declarations in general are too hard and just putting something
special in for OPTIMIZE would be acceptable, but not as nice.
I checked CLtL and the word is "declaration specifier" rather than
"declaration type" or "declaration kind". I should have checked
CLtL before I first proposed the DECLARATION function, sorry.
Date: Sun, 19 Mar 89 13:46:38 PST
From: cperdue@Sun.COM (Cris Perdue)
The language permits implementation-dependent declaration types,
so I think we want to define accessors that can also be extended
by implementations.
But the language also permits user-defined declaration specifiers via
the DECLARATION proclamation, and if this is to be real the user (not
the implementation) should be able to define declaration accessors. The
simplest answer is to say that's too far-out and we're not going to
standardize it now. The most comprehensive answer is some kind of
DEFDECLARATION that allows user control over the parsing, scoping, and
indexing of declarations, powerful enough so all the built-in
declaration specifiers could have been defined with it. An
intermediate position would be just enough to handle the miscellaneous
declarations seen in current practice, but not general enough to take
over from e.g. VARIABLE-INFORMATION. See suggestion below.
If done right, this will be another way to replace COMPILER-LET.
That is, information from an outer macro can be passed down to
an inner macro by encoding it in a declaration of a user-defined
declaration specifier.
....I think we would want to explicitly
permit implementations to add more return values to return information
about implementation-dependent declarations.
Agreed. That can be done with the stroke of a pen.
Date: Mon, 20 Mar 89 10:21:47 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
The problem I have with option 1 (adding a DECLARATION function to
access declarations) is that declarations don't have a regular syntax,
and that "decl-type" and "name" arguments might not be appropriate for
expressing the syntax of implementation-specific declarations. For
example, several implementations support declarations that control
global attributes (like downward-only closures or suppressing style
warnings) that aren't associated with any "name".
These are easy, the name can just be ignored for these declaration
specifiers. But see suggestion below.
Even more peculiar
would be something like the declaration Lucid supports that lets you
say that any objects of a given type really belong to a more specific
type (such as that all numbers will be fixnums).
This is more interesting; the "given type" can be the name, but maybe the
declaration lookup has to use the (nonexistent) function EQUAL-TYPEP
to compare the name for this declaration specifier?
Another approach would be for (DECLARATION declaration-specifier env)
to return a list of all decl-specs currently in force with the symbol
declaration-specifier in their car, sorted so the innermost declaration
is first on the list. It's then up to the caller to parse this in
whatever way is appropriate for the particular declaration-specifier.
This is crude but makes it possible to get the job done. Also this
should say that the results are unspecified (-not- undefined!) if
declaration-specifier is any built-in declaration-specifier other
than OPTIMIZE, so that implementations don't have to be able to
reproduce things like type declarations in their original form.
For implementation-dependent declaration-specifiers, require that
either DECLARATION works or the implementation provides an accessor
that is specialized for that declaration-specifier.
∂20-Mar-89 1327 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 20 Mar 89 13:26:56 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA03768; Mon, 20 Mar 89 16:06:14 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA01717; Mon, 20 Mar 89 16:08:04 EST
Message-Id: <8903202108.AA01717@mist.>
To: "sandra%defun@cs.utah.edu"@multimax.encore.com (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
In-Reply-To: Your message of Sat, 18 Mar 89 10:06:16 -0700.
<8903181706.AA08173@defun.utah.edu>
Date: Mon, 20 Mar 89 16:07:55 EST
From: Dan L. Pierson <pierson@mist.encore.com>
I like option #3 too. Among other things, the addition of NTH-VALUE
makes the other functions easy to derive if you want them, e.g.:
(DEFUN VARIABLE-TYPE (FOO)
(DECLARE (INLINE VARIABLE-TYPE))
(NTH-VALUE 2 (VARIABLE-KIND FOO)))
∂20-Mar-89 1325 CL-Cleanup-mailer Re: Issue: LOAD-OBJECTS (Version 3)
Received: from Xerox.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89 13:24:54 PST
Received: from Semillon.ms by ArpaGateway.ms ; 20 MAR 89 13:17:33 PST
Date: 20 Mar 89 13:16 PST
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
In-reply-to: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>'s message
of Sat, 18 Mar 89 01:50 EST
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Richard P. Gabriel
<rpg@lucid.com>, CL-Cleanup@sail.stanford.edu,
CL-Compiler@sail.stanford.edu, Common-Lisp-Object-System@sail.stanford.edu
Message-ID: <890320-131733-6488@Xerox>
MAKE-LOAD-FORM-USING-SLOTS is too easy to confuse with
SLOT-VALUE-USING-CLASS. MAKE-LOAD-FORM-FROM-SLOTS is better,
except for form/from dyslexia. MAKE-LOAD-FORM-FOR-SLOTS ?
How about MAKE-LOAD-FORM-SAVING-SLOTS
danny
∂20-Mar-89 1340 CL-Compiler-mailer Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 13:40:11 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561297; Mon 20-Mar-89 16:39:20 EST
Date: Mon, 20 Mar 89 16:39 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: **DRAFT** issue SYNTACTIC-ENVIRONMENT-ACCESS (version 4)
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@SAIL.STANFORD.EDU
In-Reply-To: <8903151840.AA04690@defun.utah.edu>
Message-ID: <19890320213910.6.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 15 Mar 89 11:40:35 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Date: Wed, 15 Mar 89 12:10 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> Not if you have DESTRUCTURING-BIND. But I guess that hasn't been
> accepted into the language yet.
Is there a cleanup proposal afoot to add this? I don't remember seeing
this on the list Larry distributed at the last meeting.
It's a new issue:
!* DESTRUCTURING-BIND
Version 2, 25-Jan-89, Released 16-Mar-89
Synopsis: add DESTRUCTURING-BIND macro
Status: might need new version before vote
==================================================
> PARSE-MACRO name lambda-list body &optional env [Function]
>
> Processes the lambda-list in the same way that DEFMACRO and MACROLET do.
> Returns a lambda-expression that accepts two arguments (form and env)
> and returns the macro expansion.
If this function doesn't actually do any evaluation to construct a
real function, is it really necessary to have it accept an environment
argument?
It used to need it in case it had to expand macros in the body to see if
they were declarations, but we got rid of that feature. I think it
might need it in some implementations to expand macros in order to do
code analysis on initialization forms for optional/keyword/auxiliary
variables in the lambda-list. I think it's always better to give an
environment argument to functions like this; in principle a form has no
meaning except in the context of an environment, and any function that
takes a form, or something containing forms, as an argument should take
an environment as an argument also. This would be more obvious if the
null lexical environment contained nothing, rather than containing the
bulk of the language.
==================================================
Also, a long time ago we passed a cleanup issue saying that the body
of a macro definition established with MACROLET or DEFMACRO has an
implicit BLOCK around it. Unless you want the "body" argument to
already include the BLOCK, you need the "name" argument for this
purpose. Let's be explicit about it, one way or the other.
You're right, I forgot this. PARSE-MACRO should definitely put in
the BLOCK.
==================================================
I didn't see any mail follow-up on this idea:
Symbolics Genera includes an undocumented internal macro, used
quite a bit in the implementation of the interpreter and code
analyzers, that could have been called WITH-AUGMENTED-ENVIRONMENT,
taking keywords like AUGMENT-ENVIRONMENT and also body forms,
and producing an environment with dynamic extent bound to a
variable within the body forms. Would it be useful to have this
too, or instead of AUGMENT-ENVIRONMENT? I'm unsure.
I wasn't able to think of any applications for AUGMENT-ENVIRONMENT
that would not be happy using WITH-AUGMENTED-ENVIRONMENT instead.
That certainly does not prove that there aren't any.
==================================================
> The possible interpreter implementation of COMPILER-LET I mentioned
> in another message earlier today would seem to require another
> keyword argument to AUGMENT-ENVIRONMENT. Does this mean that we
> have to dictate some particular interpreter implementation of
> COMPILER-LET? I'm unsure.
I believe so. It wouldn't work for a user codewalker to bind
COMPILER-LET variables specially before walking the body, if
MACROEXPAND-1 is going to look in the environment for variables to
bind. (It may mistakenly bind a variable in an outer contour that is
supposed to be shadowed by one the codewalker bound.) And it wouldn't
work for code walkers just to add the bindings to the environment if
MACROEXPAND-1 doesn't look for them.
Do you really want to go ahead with this idea? At the very least, I
think it would have to be presented as a separate proposal from
COMPILER-LET-CONFUSION:REPAIR, instead of just suggested as a way to
implement that proposal.
This should be followed up. I guess a separate proposal is a good idea.
I think COMPILER-LET-CONFUSION:REPAIR should be split into four proposals.
First, one that gives the general framework for repairing but doesn't
say anything about how the interpreter implements COMPILER-LET, other
than to say that an additional proposal is needed to cover that. Then
three proposals for how the interpreter implements COMPILER-LET:
(1) The interpreter always does a "semantic pre-pass" like the compiler.
(2) The interpreter expands all macros inside COMPILER-LET before
evaluating any of the code inside COMPILER-LET.
(3) COMPILER-LET passes the variable bindings to MACROEXPAND-1
through the lexical environment, and the time when the interpreter
expands macros is not changed.
∂20-Mar-89 1353 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Mar 89 13:51:21 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA26581; Mon, 20 Mar 89 14:50:04 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA10158; Mon, 20 Mar 89 14:49:56 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903202149.AA10158@defun.utah.edu>
Date: Mon, 20 Mar 89 14:49:55 MST
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
Cris Perdue <cperdue@Sun.COM>, cl-compiler@SAIL.STANFORD.EDU,
masinter.pa@XEROX.COM
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 20 Mar 89 16:18 EST
> Date: Mon, 20 Mar 89 16:18 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> Another approach would be for (DECLARATION declaration-specifier env)
> to return a list of all decl-specs currently in force with the symbol
> declaration-specifier in their car, sorted so the innermost declaration
> is first on the list. It's then up to the caller to parse this in
Hmmm. I think this has promise, provided that we either clarify that
for declarations that can be "bound", only those declarations that
apply to lexically visible bindings be returned, or else restrict this
to declarations that can only be "free". Also, shouldn't this
function also ought to be required to know about the DECLARATION
decl-spec as well as OPTIMIZE?
-Sandra
-------
∂20-Mar-89 1405 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 14:05:24 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561343; Mon 20-Mar-89 17:03:52 EST
Date: Mon, 20 Mar 89 17:03 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: Cris Perdue <cperdue@Sun.COM>, cl-compiler@SAIL.STANFORD.EDU, masinter.pa@XEROX.COM
In-Reply-To: <8903202149.AA10158@defun.utah.edu>
Message-ID: <19890320220334.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Mon, 20 Mar 89 14:49:55 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
> Date: Mon, 20 Mar 89 16:18 EST
> From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
>
> Another approach would be for (DECLARATION declaration-specifier env)
> to return a list of all decl-specs currently in force with the symbol
> declaration-specifier in their car, sorted so the innermost declaration
> is first on the list. It's then up to the caller to parse this in
Hmmm. I think this has promise, provided that we either clarify that
for declarations that can be "bound", only those declarations that
apply to lexically visible bindings be returned, or else restrict this
to declarations that can only be "free".
I was restricting DECLARATION to have unspecified results if used with
any of the built-in declaration specifiers that are associated with
variable bindings. But even without that restriction, I would say
that "currently in force" means "declarations whose scope includes
env" which means that for declarations attached to bindings, the
bindings must be lexically visible.
Also, shouldn't this
function also ought to be required to know about the DECLARATION
decl-spec as well as OPTIMIZE?
Right. The documentation on DECLARATION says it can only be used with
PROCLAIM, but it should still be visible here. All that that restriction
means is that you get the same answer regardless of env.
∂20-Mar-89 1417 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 20 Mar 89 14:17:05 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA08498; Mon, 20 Mar 89 14:18:50 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA26637; Mon, 20 Mar 89 14:14:54 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA02927; Mon, 20 Mar 89 14:18:31 PST
Date: Mon, 20 Mar 89 14:18:31 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903202218.AA02927@clam.sun.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM, sandra%defun@cs.utah.edu
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS
Cc: cl-compiler@SAIL.STANFORD.EDU, masinter.pa@XEROX.COM
> > Date: Mon, 20 Mar 89 16:18 EST
> > From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> >
> > Another approach would be for (DECLARATION declaration-specifier env)
> > to return a list of all decl-specs currently in force with the symbol
> > declaration-specifier in their car, sorted so the innermost declaration
> > is first on the list. It's then up to the caller to parse this in
>
> Hmmm. I think this has promise, provided that we either clarify that
> for declarations that can be "bound", only those declarations that
> apply to lexically visible bindings be returned, or else restrict this
> to declarations that can only be "free". Also, shouldn't this
> function also ought to be required to know about the DECLARATION
> decl-spec as well as OPTIMIZE?
VARIABLE-INFORMATION, FUNCTION-INFORMATION, plus an accessor of
the sort you are describing would seem quite satisfactory to me.
I realize there are technical details to be worked out.
-Cris
∂20-Mar-89 1427 CL-Cleanup-mailer Re: Issue: LOAD-OBJECTS (Version 3)
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 14:27:09 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561368; Mon 20-Mar-89 17:23:27 EST
Date: Mon, 20 Mar 89 17:23 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: Issue: LOAD-OBJECTS (Version 3)
To: Danny Bobrow <Bobrow.pa@XEROX.COM>
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Richard P. Gabriel <rpg@lucid.com>,
CL-Cleanup@SAIL.STANFORD.EDU, CL-Compiler@SAIL.STANFORD.EDU, Common-Lisp-Object-System@SAIL.STANFORD.EDU
In-Reply-To: <890320-131733-6488@Xerox>
Message-ID: <19890320222313.1.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: 20 Mar 89 13:16 PST
From: Danny Bobrow <Bobrow.pa@Xerox.COM>
MAKE-LOAD-FORM-USING-SLOTS is too easy to confuse with
SLOT-VALUE-USING-CLASS. MAKE-LOAD-FORM-FROM-SLOTS is better,
except for form/from dyslexia. MAKE-LOAD-FORM-FOR-SLOTS ?
How about MAKE-LOAD-FORM-SAVING-SLOTS
I like that name.
∂20-Mar-89 1532 CL-Compiler-mailer issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 20 Mar 89 15:32:04 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA00402; Mon, 20 Mar 89 16:29:22 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA10232; Mon, 20 Mar 89 16:29:15 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903202329.AA10232@defun.utah.edu>
Date: Mon, 20 Mar 89 16:29:12 MST
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
To: cl-compiler@sail.stanford.edu
Cc: Moon@STONY-BROOK.SCRC.Symbolics.COM, masinter.pa@XEROX.COM,
cperdue@Sun.COM
In-Reply-To: cperdue@Sun.COM (Cris Perdue), Mon, 20 Mar 89 14:18:31 PST
OK, here's a new, improved writeup on this issue that incorporates all
the changes we seem to have agreed on. If this doesn't say what you
thought it would, let me know.
Forum: Compiler
Issue: SYNTACTIC-ENVIRONMENT-ACCESS
References: CLtL Chapter 8: Macros
Issue MACRO-FUNCTION-ENVIRONMENT
Issue GET-SETF-METHOD-ENVIRONMENT
Issue COMPILE-FILE-ENVIRONMENT
Related Issues: Issue FUNCTION-NAME
Issue PROCLAIM-LEXICAL
Issue MACRO-ENVIRONMENT-EXTENT
Issue DESTRUCTURING-BIND
Category: ADDITION
Edit history: Version 1, 2-Oct-88, Eric Benson
Version 2, 17-Feb-89, Kim A. Barrett
Version 3, 9-Mar-89, Kim A. Barrett (respond to comments)
Version 4, 12-Mar-89, Sandra Loosemore (more revisions)
Version 5, 20-Mar-89, Sandra Loosemore (only proposal SMALL)
Status: **DRAFT**
Problem description:
When macro forms are expanded, the expansion function is called with
two arguments: the form to be expanded, and the environment in which
the form was found. The environment argument is of limited utility.
The only use sanctioned currently is as an argument to MACROEXPAND or
MACROEXPAND-1 or passed directly as an argument to another macro
expansion function. Recent cleanup issues propose to allow it as an
argument to MACRO-FUNCTION and to GET-SETF-METHOD.
It is very difficult to write a code walker that can correctly handle
local macro and function definitions, due to insufficient access to
the information contained in environments and the inability to
augment environments with local definitions.
Proposal (SYNTACTIC-ENVIRONMENT-ACCESS:SMALL):
The following functions provide information about syntactic
environment objects. In all of these functions the argument named ENV
is an environment of the sort received by the &ENVIRONMENT argument to
a macro or as the environment argument for EVALHOOK. (It is not
required that implementations provide a distinguished representation
for such objects.) Optional "env" arguments default to NIL, which
represents the local null lexical environment (containing only global
definitions and proclamations that are present in the runtime
environment). All of these functions should signal an error of type
TYPE-ERROR if the value of an environment argument is not a syntactic
environment.
The accessors VARIABLE-INFORMATION, FUNCTION-INFORMATION, and
DECLARATION retrieve information about declarations that are in
effect in the environment. Since implementations are permitted to
ignore declarations (except for SPECIAL declarations), these accessors
are required only to return information about declarations that were
explicitly added to the environment using AUGMENT-ENVIRONMENT.
Implementations are also permitted to canonicalize declarations, so
the information returned by the accessors may not be identical to
the information that was passed to AUGMENT-ENVIRONMENT.
VARIABLE-INFORMATION variable &optional env [Function]
This function returns information about the interpretation of the
symbol VARIABLE when it appears as a variable within the lexical
environment ENV. At least the following four values are returned;
implementations are permitted to extend this function to return
additional values.
The first value indicates the type of definition or binding which is
apparent in ENV:
NIL There is no apparent definition or binding for variable.
:SPECIAL VARIABLE refers to a special variable, either declared
or proclaimed.
:LEXICAL VARIABLE refers to a lexical variable.
:SYMBOL-MACRO VARIABLE refers to a SYMBOL-MACROLET binding.
:CONSTANT VARIABLE refers to a named constant, defined by
DEFCONSTANT.
[Note: If issue PROCLAIM-LEXICAL passes, then the :LEXICAL result
will also refer to variables proclaimed lexical.]
The second value indicates whether there is a local binding of the
name. If the name is locally bound, the second value is true.
Otherwise, NIL is returned.
The third value is the type specifier associated with the variable
named by the symbol in the environment. If no explicit association
exists, either by PROCLAIM or DECLARE, then the result is the type
specifier T. It is permissible for implementations to return a type
specifier that is equivalent to or a supertype of the one appearing
in the original declaration.
The fourth value is true if the variable has been declared IGNORE.
If no such declaration has been made or the information is not
available, NIL is returned.
FUNCTION-INFORMATION function &optional env [Function]
This function returns information about the interpretation of the
function name FUNCTION when it in a functional position within
lexical environment ENV. At least the following four values are
returned; implementations are permitted to extend this function to
return additional values.
The first value indicates the type of definition or binding of
the function name which is apparent in ENV:
NIL There is no apparent definition for FUNCTION.
:FUNCTION FUNCTION refers to a function.
:MACRO FUNCTION refers to a macro.
:SPECIAL-FORM FUNCTION refers to a special form.
Some function names may refer to both a global macro and a global
special form. In such a case, the macro takes precedence, and
:MACRO is returned as the first value.
The second value specifies whether the definition is local or
global. If local, the second value is true, and it is false when
the definition is global.
The third value is the type specifier associated with the function
in the environment, or the symbol FUNCTION if there is no functional
type declaration or proclamation associated with the function. This
value might not include all the apparent FTYPE declarations for
FUNCTION. It is permissible for implementations to return a type
specifier that is equivalent to or a supertype of the one that
appeared in the original declaration.
The fourth value is one of the symbols :INLINE, :NOTINLINE, or NIL,
depending on whether the function has been declared INLINE or NOTINLINE.
NIL is returned if there are no such declarations present or if the
information cannot be determined.
[Note: The use of "function name" rather than "symbol" as the
description of the function argument is intended to be compatible
with the various proposals to extend the syntax of function
specifiers. If no such change actually occurs then this would only
refer to symbols.]
AUGMENT-ENVIRONMENT env &KEY variable
symbol-macro
function
macro
declare [Function]
This function returns a new environment containing the information
present in ENV, augmented with the information provided by the keyword
arguments. The arguments are supplied as follows:
:VARIABLE A list of symbols which shall be visible as bound
variables in the new environment. Whether each
binding is to be interpreted as special or lexical
depends on SPECIAL declarations recorded in the
environment or provided in the :DECLARE argument list.
:SYMBOL-MACRO A list of symbol macro definitions, specified as a
list of (name definition) lists (that is, in the same
format as the CADR of a SYMBOL-MACROLET special form).
The new environment will have local symbol-macro bindings
of each symbol to the corresponding expansion, so that
MACROEXPAND will be able to expand them properly.
:FUNCTION A list of function names which shall be visible as local
function bindings in the new environment.
:MACRO A list of local macro definitions, specified as a
list of (name definition) lists. Each definition must
be a function of two arguments (a form and an environment).
The new environment will have local macro bindings of each
name to the corresponding expander function, which
will be returned by MACRO-FUNCTION and used by
MACROEXPAND.
:DECLARE A list of decl-specs. Information about these
declarations can be retrieved from the resulting
environment using the VARIABLE-INFORMATION,
FUNCTION-INFORMATION, and DECLARATION accessors.
An error is signalled if any of the symbols naming macros in the
:SYMBOL-MACRO alist are also included in the :VARIABLE list.
An error is signalled if any of the names specified as keys in the
:MACRO alist are also included in the :FUNCTION list. The consequences
of destructively modifying the list structure of any of the arguments
to this function are undefined.
The extent of the returned environment is the same as the extent of
the argument environment. The result may share structure with the
argument environment, but the argument environment is not modified.
While an environment argument from EVALHOOK is permitted to be used
as the environment argument for this function, the reverse is not
true. If an attempt is made to use the result of AUGMENT-ENVIRONMENT
as the environment argument for EVALHOOK, the consequences are
undefined. The environment returned by AUGMENT-ENVIRONMENT may only
be used for syntactic analysis, ie. the functions specified by this
proposal and functions such as MACROEXPAND.
PARSE-MACRO name lambda-list body &optional env [Function]
This function is used to process a macro definition in the same way
as DEFMACRO and MACROLET. It returns a lambda-expression that accepts
two arguments (a form and an environment). The "name", "lambda-list",
and "body" arguments correspond to the parts of a DEFMACRO or MACROLET
definition.
The "lambda-list" argument may include &ENVIRONMENT and &WHOLE.
The "name" argument is used to enclose the "body" in an implicit
BLOCK, and may also be used for implementation-dependent purposes
(such as including the name of the macro in error messages if the
form does not match the lambda-list).
DECLARATION decl-spec &optional env [Function]
This function returns a list of declaration-specifiers whose CAR
is the symbol DECL-SPEC that are in force in the environment ENV,
sorted so that the innermost declaration is first on the list.
It is required that this function recognize OPTIMIZE and DECLARATION
declarations. The results are unspecified for any other built-in
declaration-specifier.
If an implementation has been extended to recognize additional
declaration specifiers in DECLARE or PROCLAIM, it is required that
either the DECLARATION function should also recognize those
declarations, or that the implementation provide an accessor that is
specialized for that declaration specifier. Note that if an
extended declaration specifier may be "bound", this function should
return only those declarations that apply to the lexically visible
binding.
Rationale:
This proposal defines a minimal set of accessors and a constructor
for environments.
The PARSE-MACRO function is provided so that users don't have to
write their own code to destructure macro arguments. Most
implementations probably already have a similar internal function.
Making TYPE and FTYPE declarations optional continues to allow
implementations the freedom to simply ignore all such declarations.
The same holds true for other declarations accessed with the
DECLARATION function.
Examples:
#1: This example illustrates the first value returned by the function
VARIABLE-INFORMATION.
(DEFMACRO KIND-OF-VARIABLE (VAR &ENVIRONMENT ENV)
`',(VARIABLE-INFORMATION VAR ENV))
(DEFVAR A)
(DEFUN TEST ()
(LET (B)
(LET (C)
(DECLARE (SPECIAL C))
(SYMBOL-MACROLET ((D ANYTHING))
(LIST (KIND-OF-VARIABLE A)
(KIND-OF-VARIABLE B)
(KIND-OF-VARIABLE C)
(KIND-OF-VARIABLE D)
(KIND-OF-VARIABLE E))))))
(TEST) -> (:SPECIAL :LEXICAL :SPECIAL :SYMBOL-MACRO NIL)
#2: This example illustrates the first value returned by the function
FUNCTION-INFORMATION.
(DEFMACRO KIND-OF-FUNCTION (FUNCTION-NAME &ENVIRONMENT ENV)
`',(FUNCTION-INFORMATION FUNCTION-NAME ENV))
(DEFUN A ())
(DEFMACRO B ())
(DEFUN TEST ()
(FLET ((C ()))
(MACROLET ((D ()))
(MULTIPLE-VALUE-CALL #'LIST
(KIND-OF-FUNCTION A)
(KIND-OF-FUNCTION B)
(KIND-OF-FUNCTION QUOTE)
(KIND-OF-FUNCTION C)
(KIND-OF-FUNCTION D)
(KIND-OF-FUNCTION E)))))
(TEST) -> (:FUNCTION NIL
:MACRO NIL
:SPECIAL-FORM NIL
:FUNCTION T
:MACRO T
NIL NIL)
#3: This example shows how a code-walker might walk a MACROLET special
form.
(defun walk-macrolet (form env)
(let ((macros (make-macro-definitions (cadr form) env)))
(multiple-value-bind (body decls) (parse-body (cddr form))
(walk-implicit-progn
body
(augment-environment env :macro macros :declare decls))
)))
(defun make-macro-definitions (defs env)
(let ((results nil))
(dolist (d defs)
(push (list (car d)
(coerce (parse-macro (car d) (cadr d) (cddr d) env)
'function))
results))
results))
Cost to Implementors:
Most implementations already record some of this information in some
form. Providing these functions should not be too difficult, but it
is a more than trivial amount of work.
Cost to Users:
This change is upward compatible with user code.
Current practice:
No implementation provides all of this interface currently. Portable
Common Loops defines a subset of this functionality for its code
walker and implements it on a number of diffent versions of Common
Lisp.
Discussion:
The first version of this proposal expressly did not deal with the
objects which are used as environments by EVALHOOK. This version is
extended to support them in the belief that such environments share a
lot of functionality with the syntactic environments needed by a
compiler. While the two types of environments might have very
different implementations, there are many operations which are
reasonable to perform on either type, including all of the accessor
functions described by this proposal.
AUGMENT-ENVIRONMENT currently requires signaling an error when
symbol-macro names match variable names in the same call. This could
be reduced to "should signal". By requiring the error signaling, this
proposal is compatable with Proposal SYMBOL-MACROLET-DECLARE:ALLOW,
which says
"... signals an error if a SPECIAL declaration names one of the symbols
being defined as a symbol-macrolet."
Maintaining compatability with the SYMBOL-MACROLET-DECLARE proposal
allows fairly trivial implementations of the SYMBOL-MACROLET
special-form in terms of the AUGMENT-ENVIRONMENT function.
Moon notes:
Symbolics Genera includes an undocumented internal macro, used
quite a bit in the implementation of the interpreter and code
analyzers, that could have been called WITH-AUGMENTED-ENVIRONMENT,
taking keywords like AUGMENT-ENVIRONMENT and also body forms,
and producing an environment with dynamic extent bound to a
variable within the body forms. Would it be useful to have this
too, or instead of AUGMENT-ENVIRONMENT? I'm unsure.
Some people have indicated they think that the :MACRO argument (and
the :SYMBOL-MACRO argument too?) to AUGMENT-ENVIRONMENT should be an
a-list of the form (name . definition).
-------
∂20-Mar-89 1612 CL-Compiler-mailer issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
Received: from lucid.com by SAIL.Stanford.EDU with TCP; 20 Mar 89 16:12:34 PST
Received: from blacksox ([192.9.201.39]) by heavens-gate.lucid.com id AA05421g; Mon, 20 Mar 89 16:05:41 PST
Received: by blacksox id AA00812g; Mon, 20 Mar 89 16:09:38 PST
Date: Mon, 20 Mar 89 16:09:38 PST
From: Eric Benson <eb@lucid.com>
Message-Id: <8903210009.AA00812@blacksox>
To: sandra%defun@cs.utah.edu
Cc: cl-compiler@sail.stanford.edu, Moon@STONY-BROOK.SCRC.Symbolics.COM,
masinter.pa@XEROX.COM, cperdue@Sun.COM
In-Reply-To: Sandra J Loosemore's message of Mon, 20 Mar 89 16:29:12 MST <8903202329.AA10232@defun.utah.edu>
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
This doesn't provide a way to distinguish pervasively SPECIAL
(proclaimed) variables from locally SPECIAL (declared) variables.
This is important because new bindings of names which are pervasively
SPECIAL are special bindings, while new bindings of names which are
locally SPECIAL (except those to which the declaration is attached)
are lexical bindings. This is just the sort of thing a code walker
should do correctly. I propose that instead of VARIABLE-INFORMATION
returning :SPECIAL as the first value, it should return
:PROCLAIMED-SPECIAL or :DECLARED-SPECIAL.
I would be happier if this difference between SPECIAL proclamations
and SPECIAL declarations were removed. Does anyone have an opinion on
this? I guess it's too late for another cleanup issue.
∂20-Mar-89 2032 CL-Compiler-mailer issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 20 Mar 89 20:32:04 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 561653; Mon 20-Mar-89 23:31:12 EST
Date: Mon, 20 Mar 89 23:30 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
To: Eric Benson <eb@lucid.com>
cc: sandra%defun@cs.utah.edu, cl-compiler@SAIL.STANFORD.EDU, masinter.pa@XEROX.COM,
cperdue@Sun.COM
In-Reply-To: <8903210009.AA00812@blacksox>
Message-ID: <19890321043051.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Mon, 20 Mar 89 16:09:38 PST
From: Eric Benson <eb@lucid.com>
This doesn't provide a way to distinguish pervasively SPECIAL
(proclaimed) variables from locally SPECIAL (declared) variables.
This is important because new bindings of names which are pervasively
SPECIAL are special bindings, while new bindings of names which are
locally SPECIAL (except those to which the declaration is attached)
are lexical bindings.
Good point.
This is just the sort of thing a code walker
should do correctly. I propose that instead of VARIABLE-INFORMATION
returning :SPECIAL as the first value, it should return
:PROCLAIMED-SPECIAL or :DECLARED-SPECIAL.
If PROCLAIM-LEXICAL passes, the same issue will arise for LEXICAL. I
suggest that either the global binding type be returned as an additional
value, or that the programmer be reminded that the global binding type
may differ from the local one and can be retrieved by calling
VARIABLE-INFORMATION again with a null lexical environment.
I would be happier if this difference between SPECIAL proclamations
and SPECIAL declarations were removed. Does anyone have an opinion on
this? I guess it's too late for another cleanup issue.
Removing that difference would be a disaster, since if you made SPECIAL
proclamations shadowable by bindings there would be no way to express
DEFVAR in terms of other constructs, and if you made SPECIAL
declarations not shadowable by bindings the scoping rules for
declarations would be inconsistent, unless you made all declarations not
shadowable by bindings, in which case (surprise!) you would be back to
the declaration scoping rules of Maclisp and ZetaLisp, which back in
1982 when all this was designed were considered terrible.
Vive la difference!
∂21-Mar-89 0614 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Mar 89 06:14:50 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA12519; Tue, 21 Mar 89 07:14:13 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA10699; Tue, 21 Mar 89 07:14:08 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903211414.AA10699@defun.utah.edu>
Date: Tue, 21 Mar 89 07:14:06 MST
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Eric Benson <eb@lucid.com>, cl-compiler@SAIL.STANFORD.EDU,
masinter.pa@XEROX.COM, cperdue@Sun.COM
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Mon, 20 Mar 89 23:30 EST
Perhaps we could use the (newly added) second return value from
VARIABLE-INFORMATION to tell whether the declaration or definition of
the variable is local or global, instead of whether there is a local
binding of the variable. That would complicate things a little
though, because the interpretation of the second value would depend on
the first:
First value Second value
NIL Always NIL
:SPECIAL T = declared special, NIL = proclaimed special
:LEXICAL T = declared lexical or assumed lexical because of
local binding, NIL = proclaimed lexical
:SYMBOL-MACRO Always T
:CONSTANT Always NIL
-Sandra
-------
∂21-Mar-89 0738 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 21 Mar 89 07:38:18 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA08780; Tue, 21 Mar 89 10:38:02 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA02608; Tue, 21 Mar 89 10:39:56 EST
Message-Id: <8903211539.AA02608@mist.>
To: "sandra%defun@cs.utah.edu"@multimax.encore.com (Sandra J Loosemore)
Cc: cl-compiler@SAIL.STANFORD.EDU
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
In-Reply-To: Your message of Tue, 21 Mar 89 07:14:06 -0700.
<8903211414.AA10699@defun.utah.edu>
Date: Tue, 21 Mar 89 10:39:53 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Perhaps we could use the (newly added) second return value from
VARIABLE-INFORMATION to tell whether the declaration or definition of
the variable is local or global, instead of whether there is a local
binding of the variable. That would complicate things a little
though, because the interpretation of the second value would depend on
the first:
First value Second value
NIL Always NIL
:SPECIAL T = declared special, NIL = proclaimed special
:LEXICAL T = declared lexical or assumed lexical because of
local binding, NIL = proclaimed lexical
:SYMBOL-MACRO Always T
:CONSTANT Always NIL
Seems reasonable. I don't think the complication is significant since
what you want to do is likely to change as the first value changes anyway.
∂21-Mar-89 0843 Common-Lisp-Object-System-mailer Compile Time Class Creation (was: remote environments)
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 21 Mar 89 08:42:47 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA28027; Tue, 21 Mar 89 08:44:46 PST
Received: from suntana.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA28469; Tue, 21 Mar 89 08:40:55 PST
Received: from localhost by suntana.sun.com (4.0/SMI-4.0)
id AA01870; Tue, 21 Mar 89 08:42:58 PST
Message-Id: <8903211642.AA01870@suntana.sun.com>
To: cl-compiler@sail.stanford.edu, common-lisp-object-system@sail.stanford.edu
Subject: Compile Time Class Creation (was: remote environments)
Date: Tue, 21 Mar 89 08:42:55 PST
From: kempf@Sun.COM
I've just had time to plough through the X3 mail on CLOS and there was
a point lurking in the correspondence on this topic that I think was
never clearly articulated. That point has to do with the role of
class objects in type checking and inference.
If the goal is to enable compiler implementors and extenders to write
type checking and inference code in an object-oriented way, then some
kind of object representing the class must be created at compile time.
The entire class need not be defined. For example, the slot accessor
method certainly don't need to be defined.
I think the minimum amount of information which needs to be there is the
following:
-class precedence list-Because the class precedence list is used
in subtyping, it must be available to the type checker.
-slot location (instance, class)-The compiler might be able to
optimize slot access based on this.
-slot type-Again, potentially necessary for slot access.
-metaclass-Needed for slot access, possibly to optimize instance
creation and initialization.
-interface information for slot access functions-So they can
be optimized.
Most compilers currently use list structures for their type checkers, and
it certainly would be possible to disallow compile time creation of
classes for standard-class objects, to simplify things. But to do so
for the metaobject protocol would limit the metaobject protocol in
a way that would be crippling, since the point of the metaobject protocol
is to allow extensibility in the language processing software.
There are a number of possible decisions. It could be left either
unintentionally or deliberately ambiguous. It could be specified that
standard-class objects either are created, are partially created, or
are not created at compile time, while leaving open the question for
other metaclasses (since the MOP will probably not be a part of the
official ANSI Common Lisp '89 standard anyway). However, it is important
to understand the effect of these decisions on future evolution and
user extensibility.
jak
∂21-Mar-89 0911 CL-Compiler-mailer issue DEFINE-OPTIMIZER, version 5
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Mar 89 09:11:01 PST
Received: from wheat-chex.ai.mit.edu by life.ai.mit.edu; Tue, 21 Mar 89 12:10:44 EST
Received: from localhost by wheat-chex.ai.mit.edu; Tue, 21 Mar 89 12:10:40 EST
Date: Tue, 21 Mar 89 12:10:40 EST
From: dick@wheaties.ai.mit.edu
Message-Id: <8903211710.AA06262@wheat-chex.ai.mit.edu>
To: cl-compiler@sail.stanford.edu
Cc: cperdue@sun.com, dick@wheaties.ai.mit.edu
In-Reply-To: Sandra J Loosemore's message of Mon, 13 Mar 89 16:31:17
Subject: issue DEFINE-OPTIMIZER, version 5
Cris perdue was kind enough to send a copy of this proposal to me.
I would like to say that I think that compiler optimizers are an
extremely good idea---right up there with the best of the ideas ever
presented to the committee.
I really hate having to make things macros for trivial reasons,
because this blocks you from funcalling them and using them as
arguments to MAPCAR REDUCE etc. If this mechanism were in Common Lisp
I would use it all the time. I bet it would cover a significant chunk
of what I use macros for.
To be more specific, there are a number of places where such compiler
optimizers would be of HUGE benefit in my portable implementation of
SERIES. In particular, they would be an appropriate framework in
which to state the whole thing. Now, since I have to do it all with
macros, a number of things that should, by every right, be functions
have to be macros instead. This in fact makes it impossible to make an
implementation of what I really want.
Much as I like the proposal, I think there are a couple of places
where it might be improved.
(1) you might consider having OPTIMIZE-EXPRESSION-1 act like
MACRO-EXPAND-1 when given a macro call. Or alternatively, have a
function called OPTIMIZE-OR-EXPAND-EXPRESSION-1. Otherwise, code
walkers are going to have to implement this functionality themselves
since optimizations can expand into macros and vice versa.
(2) The same of course goes for OPTIMIZE-EXPRESSION.
(3) Perhaps the proposal cannot require an implementation to actually
use the optimizers. However, it should certainly encourage
compilers to use them in the strongest possible terms.
(4) I agree that things should be kept simple and not get into pattern
matching etc.
(5) I agree with what Barrett says about the interaction of
inline/noinline and optimizers.
In summary, I recommend the inclusion of this idea in the strongest
possible terms. In particular, although I think the ideas above would
be improvements, I would much rather see the proposal accepted as is
rather than not accepted.
Dick Waters
∂21-Mar-89 0932 CL-Compiler-mailer issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 21 Mar 89 09:32:06 PST
Received: from wheat-chex.ai.mit.edu by life.ai.mit.edu; Tue, 21 Mar 89 12:32:06 EST
Received: from localhost by wheat-chex.ai.mit.edu; Tue, 21 Mar 89 12:32:05 EST
Date: Tue, 21 Mar 89 12:32:05 EST
From: dick@wheaties.ai.mit.edu
Message-Id: <8903211732.AA06334@wheat-chex.ai.mit.edu>
To: cl-compiler@sail.stanford.edu
Cc: cperdue@sun.com, dick@wheaties.ai.mit.edu
In-Reply-To: Sandra J Loosemore's message of Sun Mar 12 10:18:08 1989
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
Cris Perdue was kind enough to send a copy of this proposal on to me.
I think that this fills an obvious hole in Common Lisp and should be
adopted. It would definitely have been useful to me in implementing
my SERIES macro package. However, I think that there are a couple of problems.
(1) The proposal should say somewhere what happens if an environment
gets returned out of its dynamic context. In particular, what happens
in the first example if KIND-OF-VARIABLE is defined as follows:
(DEFMACRO KIND-OF-VARIABLE (VAR &ENVIRONMENT ENV)
`(VARIABLE-KIND ',VAR ',ENV))
I assume very bad things happen.
(2) I think it is very odd indeed to allow implementations to ignore
type and ftype information and fail to put it in the environment.
(3) I do not understand why we need to have AUGMENT-ENVIRONMENT.
Except for the recently added :declare argument it is completely
redundant with LET, SYMBOL-MACROLET, FLET, and MACROLET.
What is worse, while AUGMENT-ENVIRONMENT fully captures the
functionality of SYMBOL-MACROLET, and MACROLET, it behaves very oddly
with regard to LET and FLET. In particular, if I understand it right,
it could be used to set things up so that the compiler thought a given
variable was a local varible, but it does nothing to actually create the
variable so things can be stored in it. What does this even mean?
The same goes for FLET. What function is going to end up being called
when instances of the given function appear? Perhaps the compiler is
supposed to be able to work all this out. If so this needs to be explained.
I would strongly recommend that AUGMENT-ENVIRONMENT be eliminated.
It just is not that hard to have macros expand into the right uses of
let-like forms before recursing to do further processing. In any
case, it seems that they will have to continue doing that for LET and
FLET even if AUGMENT-ENVIRONMENT is retained.
(4) I agree that things should be kept just to the smallest proposal.
Dick waters.
∂21-Mar-89 1020 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 10:19:57 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562040; Tue 21-Mar-89 13:16:45 EST
Date: Tue, 21 Mar 89 13:16 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: Eric Benson <eb@lucid.com>, cl-compiler@SAIL.STANFORD.EDU, masinter.pa@XEROX.COM,
cperdue@Sun.COM
In-Reply-To: <8903211414.AA10699@defun.utah.edu>
Message-ID: <19890321181630.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
Date: Tue, 21 Mar 89 07:14:06 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Perhaps we could use the (newly added) second return value from
VARIABLE-INFORMATION to tell whether the declaration or definition of
the variable is local or global, instead of whether there is a local
binding of the variable.
Losing the information about whether there is a local binding seems
like a bad idea.
∂21-Mar-89 1338 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
Received: from ti.com by SAIL.Stanford.EDU with TCP; 21 Mar 89 13:38:30 PST
Received: by ti.com id AA05344; Tue, 21 Mar 89 15:03:35 CST
Received: from Kelvin by tilde id AA23983; Tue, 21 Mar 89 14:50:23 CST
Message-Id: <2815505310-8473304@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 21 Mar 89 14:48:30 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu, Moon@STONY-BROOK.SCRC.Symbolics.COM,
cperdue@Sun.COM
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
In-Reply-To: Msg of Mon, 20 Mar 89 16:29:12 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)
> DECLARATION decl-spec &optional env [Function]
>
> This function returns a list of declaration-specifiers whose CAR
> is the symbol DECL-SPEC that are in force in the environment ENV,
> sorted so that the innermost declaration is first on the list.
>
> It is required that this function recognize OPTIMIZE and DECLARATION
> declarations. The results are unspecified for any other built-in
> declaration-specifier.
I'm uneasy about the notion of the notion of returning all the
declarations, innermost first. First, note that since DECLARATION is only
valid in PROCLAIM, there isn't any lexical ordering. OPTIMIZE
declarations do have lexical shadowing, but is that really relevant?
Don't you just want to know what the current values are, not all the
history of how they got that way? For example, given
(defmacro show-opt (&environment e)
(print (declaration 'optimize e)))
(proclaim '(optimize (speed 1)))
(defun ff (x)
(declare (optimize (space 2)))
...
(dotimes (i n)
(declare (optimize speed))
(show-opt)
...) ...)
this specification would lead one to expect the value printed to be
((OPTIMIZE SPEED) (OPTIMIZE (SPACE 2)) (OPTIMIZE (SPEED 1)))
It should be valid for an implementation to return, for example:
((OPTIMIZE (SAFETY 1) (SPACE 2) (SPEED 3)))
because all the compiler cares about or wants to remember are the current
values. (Any implementation that really uses OPTIMIZE declarations is
going to want to have a more efficient way of accessing them than searching
through a list. The same thing applies to a macro that wants to use this
information; requiring them to search a list for what they want would
discourage the use of this feature.) I think I'd rather see
(DECLARATION 'OPTIMIZE env) => ((quality value)...)
(DECLARATION 'DECLARATION env => (symbol symbol ...)
Note that this approach makes it much easier to do something like this:
(let ((save-opt (declaration 'optimize)))
(proclaim '(optimize ...))
(compile-file ...)
(proclaim `(optimize . ,save-opt))) ; restore previous values
> ... Note that if an
> extended declaration specifier may be "bound", this function should
> return only those declarations that apply to the lexically visible
> binding.
The binding of what? Probably you mean "... that apply to some binding
which is lexically visible"? I don't think this is feasible -- if binding
declarations are stored in the variable table entry, then it is not
reasonable to be asked for a list of all of them, while if you use a list
as a stack of declarations, then you don't have an easy way to keep track
of which ones are connected to non-shadowed variables. Better to say that
the DECLARATION function is only for pervasive declarations.
Also, in regard to binding declarations, instead of just saying that
VARIABLE-INFORMATION can return additional values, how about saying that
the fifth value is a property list of implementation-dependent
declaration keys and values? That way, extensions developed at different
places could later be mixed together rather than necessarily being
mutually incompatible.
∂21-Mar-89 1344 CL-Compiler-mailer issue DEFINING-MACROS-NON-TOP-LEVEL
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Mar 89 13:44:21 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA27204; Tue, 21 Mar 89 14:42:29 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA10892; Tue, 21 Mar 89 14:42:14 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903212142.AA10892@defun.utah.edu>
Date: Tue, 21 Mar 89 14:42:12 MST
Subject: issue DEFINING-MACROS-NON-TOP-LEVEL
To: cl-compiler@sail.stanford.edu
Cc: moon@stony-brook.scrc.symbolics.com
Moon and I have exchanged some private mail on this issue that has
turned up something very troublesome. It has to do with the part of
the proposal that says that macro functions created by DEFMACRO are
evaluated in the lexical environment in which the defining macro
appears, and Moon's suggestion that MACROLET macro functions also be
evaluated in a possibly non-null lexical environment.
The problem is that there isn't a convenient way for code-walkers (and
presumably compilers) to do this, even with our proposal for issue
SYNTACTIC-ENVIRONMENT-ACCESS. Basically, you would have to do two
code walkers -- one to do a total macroexpansion on the body of macro
functions before coercing it to be a function, and another to do what
you really wanted the code walker to do in the first place. What's
more, I'm confused about the correctness of simply evaluating the
fully-macroexpanded macro function with EVAL because of the
possibility of the environment containing SPECIAL or LEXICAL
declarations that wouldn't be picked up.
I don't think that going back to the CLtL position that all macro
functions are defined in a null lexical environment is consistent with
our current model of how defining macros work. Our model says that
DEFMACRO's expansion should include something like
(function (lambda ...))
Ensuring that the macro gets defined in a null environment (even if
the DEFMACRO appears in a non-null environment) would mean it would
have to look something like
(eval (quote (lambda ...)))
which I think we are all pretty much agreed is wrong.
I believe we really have two choices:
(1) Change our definition of top-level back so that top-level implies
null lexical environment again, and have MACROLET continue to
evaluate the macros in a null environment. (The problem of early
evaluation in a non-null environment would never arise then.)
(2) Require implementations to provide some primitive for causing
evaluation in a non-null syntactic environment. (This is required
now internally anyway in order to support EVAL-WHEN COMPILE
evaluation.) One possibility is the ENCLOSE function that has
been mentioned in connection with the cleanup issue COERCE-INCOMPLETE,
that takes a lambda expression and a syntactic environment, and
returns a function. It would be an error for the lambda
expression to try to refer to any of the variable or function
bindings established in the environment.
Unless somebody can convince me that declarations don't really pose a
problem after all, I'm not sure if doing nothing (and requiring users
to do a lot of extra work to handle macro definitions) is a reasonable
alternative. It certainly tends to defeat the purpose of
SYNTACTIC-ENVIRONMENT-ACCESS, which was to make it easy to write a
correct code-walker.
Anybody have thoughts on this?
-Sandra
-------
∂21-Mar-89 1522 CL-Compiler-mailer issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
Received: from RIVERSIDE.SCRC.Symbolics.COM (SCRC-RIVERSIDE.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 15:18:10 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by RIVERSIDE.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 324891; Tue 21-Mar-89 18:17:17 EST
Date: Tue, 21 Mar 89 18:17 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
cc: cl-compiler@SAIL.STANFORD.EDU, masinter.pa@XEROX.COM, cperdue@Sun.COM
In-Reply-To: <8903202329.AA10232@defun.utah.edu>
Message-ID: <19890321231717.5.MOON@EUPHRATES.SCRC.Symbolics.COM>
Line-fold: No
I like this new version of SYNTACTIC-ENVIRONMENT-ACCESS:SMALL,
except for two minor comments:
The accessors VARIABLE-INFORMATION, FUNCTION-INFORMATION, and
DECLARATION retrieve information about declarations that are in
effect in the environment. Since implementations are permitted to
ignore declarations (except for SPECIAL declarations), these accessors
are required only to return information about declarations that were
explicitly added to the environment using AUGMENT-ENVIRONMENT.
I think this is wrong. Certainly if DECLARATION is to be useful
implementations must not be allowed to discard any of the declarations
it can return. As someone from an implementation that ignores type
declarations, I can say that I think all implementations should be
required to return all declarations from all three of these functions.
I think implementations should be permitted to ignore declarations
in the sense of the code generated by the compiler not being affected
by declarations, but should not be permitted to just throw declarations
away rather than putting them into the syntactic environment.
DECLARATION should be renamed DECLARATION-INFORMATION to match
with VARIABLE-INFORMATION and FUNCTION-INFORMATION.
∂21-Mar-89 1615 CL-Compiler-mailer Re: issue DEFINING-MACROS-NON-TOP-LEVEL
Received: from ti.com by SAIL.Stanford.EDU with TCP; 21 Mar 89 16:14:20 PST
Received: by ti.com id AA06212; Tue, 21 Mar 89 17:48:48 CST
Received: from Kelvin by tilde id AA27618; Tue, 21 Mar 89 17:36:29 CST
Message-Id: <2815515283-9072478@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Tue, 21 Mar 89 17:34:43 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Cc: cl-compiler@sail.stanford.edu, moon@stony-brook.scrc.symbolics.com
Subject: Re: issue DEFINING-MACROS-NON-TOP-LEVEL
In-Reply-To: Msg of Tue, 21 Mar 89 14:42:12 MST from sandra%defun@cs.utah.edu (Sandra J Loosemore)
> ... One possibility is the ENCLOSE function that has
> been mentioned in connection with the cleanup issue COERCE-INCOMPLETE,
> that takes a lambda expression and a syntactic environment, and
> returns a function.
That sounds like the right answer to me. I had been wondering earlier
today whether something like that might not be needed in order to
transform the result of PARSE-MACRO into a function object suitable for
use in the :MACRO argument of AUGMENT-ENVIRONMENT.
∂21-Mar-89 1732 CL-Compiler-mailer **DRAFT** issue CLOS-MACRO-COMPILATION, version 2
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 21 Mar 89 17:32:46 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562475; Tue 21-Mar-89 20:32:29 EST
Date: Tue, 21 Mar 89 20:32 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: **DRAFT** issue CLOS-MACRO-COMPILATION, version 2
To: cl-compiler@SAIL.STANFORD.EDU
cc: x3j13@SAIL.STANFORD.EDU
In-Reply-To: <8903132248.AA02496@defun.utah.edu>
Message-ID: <19890322013216.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
I would go with MINIMAL for now. It leaves a lot of behavior
unspecified, and we can fill in that behavior later when we
add metaobjects to the standard.
Relatively small comments:
The compiler should be allowed to warn, but not error, about
failures of lambda-list congruence between methods or generic
functions in the file being compiled and methods or generic
functions in the Lisp doing the compilation. When you say
the compiler may not "perform tests" between these, it's not
clear whether you mean to rule out only errors or both errors
and warnings.
The only thing here that might be overspecification is allowing a
DEFINE-METHOD-COMBINATION to be used later in the same compilation.
However, I see no real harm in that, and it would often be
convenient for programmers, so leave it. But if someone else
moves to remove it, I will not object.
Evaluation of the form in EQL parameter specializer names in DEFMETHOD
needs to be covered. I think this is tied up with the pending compiler
committee issue DEFCONSTANT-VALUE (whose version 2 writeup I don't like,
it's too messy). The choices seem to be to require the form in an EQL
parameter specializer name to be evaluable at compile time, to require
it to depend only on constants defined in the file being compiled, or to
permit its evaluation to be deferred until load time. I don't like the
first choice. I think for both DEFCONSTANT and EQL the semantics should
be as if it were never evaluated until load time, with the compiler
allowed to evaluate it sooner only if it can prove that that does not
change the semantics. I'd be happier if the mechanism the compiler
uses to do this tentative evaluation were made available to the user,
but that can be deferred until metaobjects.
∂21-Mar-89 1832 CL-Compiler-mailer Re: **DRAFT** issue CLOS-MACRO-COMPILATION, version 2
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 21 Mar 89 18:32:12 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA08626; Tue, 21 Mar 89 19:32:07 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA11085; Tue, 21 Mar 89 19:32:00 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903220232.AA11085@defun.utah.edu>
Date: Tue, 21 Mar 89 19:31:59 MST
Subject: Re: **DRAFT** issue CLOS-MACRO-COMPILATION, version 2
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: cl-compiler@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Tue, 21 Mar 89 20:32 EST
FYI, issue DEFCONSTANT-VALUE is supposed to be dead. It was originally
intended to amend issue COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS, but
we ended up amending that issue directly instead.
> I think for both DEFCONSTANT and EQL the semantics should
> be as if it were never evaluated until load time, with the compiler
> allowed to evaluate it sooner only if it can prove that that does not
> change the semantics.
This was what was specified for DEFCONSTANT in the initial incarnation
of COMPILE-FILE-HANDLING-OF-TOP-LEVEL-FORMS, but it seemed like
everybody (except me and possibly Walter) hated it. If we want to
make DEFCONSTANT less vague than it is now, I think a proposal to
require the initial value form to be evaluated at macroexpand time and
treated as a literal constant in the expansion would probably have
more support.
-Sandra
-------
∂22-Mar-89 0836 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 22 Mar 89 08:36:04 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 562893; Wed 22-Mar-89 11:34:39 EST
Date: Wed, 22 Mar 89 11:34 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>, Moon@STONY-BROOK.SCRC.Symbolics.COM,
cl-compiler@SAIL.STANFORD.EDU, cperdue@Sun.COM
In-Reply-To: <2815505310-8473304@Kelvin>
Message-ID: <19890322163431.7.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Tue, 21 Mar 89 14:48:30 CST
From: David N Gray <Gray@DSG.csc.ti.com>
> DECLARATION decl-spec &optional env [Function]
I'm uneasy about the notion of the notion of returning all the
declarations, innermost first.
That was done so that DECLARATION does not have to have specific
knowledge of how to deal with each different decl-spec; instead
the caller has that knowledge. Otherwise we would have to add
a way for people defining new declarations to tell DECLARATION
how to parse them and how to decide whether an inner one shadows
an outer one.
First, note that since DECLARATION is only
valid in PROCLAIM, there isn't any lexical ordering.
The proposal should say that the order of proclamations is most recent
first.
OPTIMIZE
declarations do have lexical shadowing, but is that really relevant?
Don't you just want to know what the current values are, not all the
history of how they got that way?
Of course. The issue is whether that knowledge, which is specific to
the format of the OPTIMIZE declaration, goes inside of the DECLARATION
function or goes in the caller of the DECLARATION function.
I think I'd rather see
(DECLARATION 'OPTIMIZE env) => ((quality value)...)
(DECLARATION 'DECLARATION env => (symbol symbol ...)
That was what I originally proposed, so I'd rather see it too. (Except
I also proposed an additional <name> argument, which was the quality for
OPTIMIZE, the decl-spec for DECLARATION, something else for other
declarations, in some cases ignored.) The problem is that it is not
extensible without designing another mechanism that nobody wanted to
think about right now to tell DECLARATION how to parse the declarations.
Maybe we made a wrong choice here. Do you want to propose the details
of that mechanism?
Better to say that
the DECLARATION function is only for pervasive declarations.
That would be okay with me. I'm not sure "pervasive" is the correct word,
though; I assume you mean that the DECLARATION function is only for
"declarations that do not concern themselves with variable or function
bindings".
BTW I still think DECLARATION-INFORMATION might be a better name than
DECLARATION.
Also, in regard to binding declarations, instead of just saying that
VARIABLE-INFORMATION can return additional values, how about saying that
the fifth value is a property list of implementation-dependent
declaration keys and values? That way, extensions developed at different
places could later be mixed together rather than necessarily being
mutually incompatible.
That's a good idea. In fact I think IGNORE should be on that property
list rather than being a separate value, since it's so miscellaneous.
∂22-Mar-89 0905 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Mar 89 09:05:36 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA23988; Wed, 22 Mar 89 10:00:48 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA11610; Wed, 22 Mar 89 10:00:19 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903221700.AA11610@defun.utah.edu>
Date: Wed, 22 Mar 89 10:00:17 MST
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: David N Gray <Gray@DSG.csc.ti.com>, cl-compiler@SAIL.STANFORD.EDU,
cperdue@Sun.COM
In-Reply-To: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>, Wed, 22 Mar 89 11:34 EST
We don't seem to be making much progress on resolving the problems
with accessors for declarations. I'm beginning to wonder if we should
leave out that part of the proposal entirely for now, and instead just
try to standardize the parts that we seem to agree on.
If we want to continue to work towards some solution on the problem,
my suggestion is to have the DECLARATION-INFORMATION function only be
used for pervasive declarations, and that declarations that can apply
to a function or variable binding have to be returned in a property
list from FUNCTION-INFORMATION or VARIABLE-INFORMATION.
-Sandra
-------
∂22-Mar-89 1031 CL-Compiler-mailer latest issue status summary
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Mar 89 10:31:03 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA28525; Wed, 22 Mar 89 11:30:55 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA11679; Wed, 22 Mar 89 11:30:51 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903221830.AA11679@defun.utah.edu>
Date: Wed, 22 Mar 89 11:30:49 MST
Subject: latest issue status summary
To: cl-compiler@sail.stanford.edu
Here's the latest summary of what's going on with the various issues
we have pending. The ones marked with an asterisk definitely need new
versions prepared before we can vote on them. (I've already
circulated drafts of some of these to the people who requested the
changes, and I'm working on revising the others today.) I don't plan
to revise the ones that aren't marked, so if you really want something
to happen on those issues you'd better speak up soon, and have some
specific suggestions.
My plan is to mail the new versions out to X3J13 tomorrow or Friday at
the latest.
* CLOS-MACRO-COMPILATION
Clarify the language about errors under DEFMETHOD.
* COMPILE-ENVIRONMENT-CONSISTENCY
Implementations are also permitted to signal an error if there
are discrepancies between compiletime and runtime. Clean up
error language in item 3. Minor wording changes to item 1b.
COMPILE-FILE-SYMBOL-HANDLING
* COMPILED-FUNCTION-REQUIREMENTS
Restore proposal FLUSH in response to popular demand.
Clarify relation to issue COMPILE-ARGUMENT-PROBLEMS.
* COMPILER-DIAGNOSTICS
Clean up error terminology in the section on warnings.
Add notes on use of ABORT restart and resignalling to discussion section.
* COMPILER-LET-CONFUSION
Fix bug in example code.
Clarify relation to DEFINE-OPTIMIZER.
Mention Moon's suggestion in discussion (unless a proposal is submitted)
COMPILER-VERBOSITY
* CONSTANT-CIRCULAR-COMPILATION
Change EQ to EQL, add to discussion.
* CONSTANT-COLLAPSING
Clarify wording.
* CONSTANT-COMPILABLE-TYPES
Revised with suggestions from Moon.
* CONSTANT-FUNCTION-COMPILATION
This is a new issue, split off from CONSTANT-COMPILABLE-TYPES.
Only one proposal to make handling of constant functions unspecified,
unless somebody can figure out how to specify how to dump them.
DEFCONSTANT-NOT-WIRED
None of the proposals are ready to be voted on.
* DEFINE-OPTIMIZER
Return only one value from optimizer.
Optimizer has precedence over INLINE declaration.
NOTINLINE declarations inhibit optimization.
Minor clarifications to wording.
Expand discussion section.
* DEFINING-MACROS-NON-TOP-LEVEL
Revisions per Moon. Move item 3 to EVAL-WHEN-NON-TOP-LEVEL.
* EVAL-WHEN-NON-TOP-LEVEL
Add item 3 from DEFINING-MACROS-NON-TOP-LEVEL.
LOAD-TIME-EVAL
MACRO-CACHING
Moon suggested simplifying the writeup.
MACRO-ENVIRONMENT-EXTENT
Barmar wants the copier function renamed (to what?)
PROCLAIM-ETC-IN-COMPILE-FILE
New name for DEFPROCLAIM? (no suggestions yet)
* QUOTE-SEMANTICS
Revisions to language per Moon.
SAFE-CODE
This issue has been withdrawn.
* SYNTACTIC-ENVIRONMENT-ACCESS
Unresolved problems: what to do about declaration accessors, whether
to require declarations always to be saved, and what to do about
ENCLOSE.
WITH-COMPILATION-UNIT
There have been complaints that the proposal is not ready.
-------
∂22-Mar-89 1213 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
Received: from ti.com by SAIL.Stanford.EDU with TCP; 22 Mar 89 12:13:19 PST
Received: by ti.com id AA10022; Wed, 22 Mar 89 12:48:37 CST
Received: from Kelvin by tilde id AA16309; Wed, 22 Mar 89 12:34:01 CST
Message-Id: <2815583502-434567@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 22 Mar 89 12:31:42 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: dick@wheaties.ai.mit.edu
Cc: cl-compiler@sail.stanford.edu, cperdue@sun.com
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
In-Reply-To: Msg of Tue, 21 Mar 89 12:32:05 EST from dick@wheaties.ai.mit.edu
> (1) The proposal should say somewhere what happens if an environment
> gets returned out of its dynamic context.
That is addressed by a separate proposal.
> What is worse, while AUGMENT-ENVIRONMENT fully captures the
> functionality of SYMBOL-MACROLET, and MACROLET, it behaves very oddly
> with regard to LET and FLET. In particular, if I understand it right,
> it could be used to set things up so that the compiler thought a given
> variable was a local varible, but it does nothing to actually create the
> variable so things can be stored in it. What does this even mean?
The result of AUGMENT-ENVIRONMENT can be passed to MACROEXPAND or the
various environment accessors, but it is not intended that the compiler
or evaluator would ever see it. In fact, there is no way proposed that
an environment object can be given to the compiler.
∂22-Mar-89 1219 CL-Compiler-mailer issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 22 Mar 89 12:19:13 PST
Received: from wheat-chex.ai.mit.edu by life.ai.mit.edu; Wed, 22 Mar 89 15:19:42 EST
Received: from localhost by wheat-chex.ai.mit.edu; Wed, 22 Mar 89 15:19:40 EST
Date: Wed, 22 Mar 89 15:19:40 EST
From: dick@wheaties.ai.mit.edu
Message-Id: <8903222019.AA10986@wheat-chex.ai.mit.edu>
To: Gray@dsg.csc.ti.com
Cc: cl-compiler@sail.stanford.edu, cperdue@sun.com, dick@wheaties.ai.mit.edu
In-Reply-To: David N Gray's message of Wed, 22 Mar 89 12:31:42 CST <2815583502-434567@Kelvin>
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
> What is worse, while AUGMENT-ENVIRONMENT fully captures the
> functionality of SYMBOL-MACROLET, and MACROLET, it behaves very oddly
> with regard to LET and FLET. In particular, if I understand it right,
> it could be used to set things up so that the compiler thought a given
> variable was a local varible, but it does nothing to actually create the
> variable so things can be stored in it. What does this even mean?
The result of AUGMENT-ENVIRONMENT can be passed to MACROEXPAND or the
various environment accessors, but it is not intended that the compiler
or evaluator would ever see it. In fact, there is no way proposed that
an environment object can be given to the compiler.
Yes, I should have put that differently.
In particular, if I understand it right, AUGMENT-ENVIRONMENT could
be used to set things up so that inner macroexpansions using the
environment think a given variable is a lexical variable, but it
does nothing to actually create the variable so things can be stored
in it. What does this even mean?
Consider the following example. It is not clear exactly what some
macro might do with the knowledge that a variable is local, so I have
just made something up. However, whatever a macro did with this
information, it would not do the right thing if the information was
wrong, and AUGMENT-ENVIRONMENT makes it very easy for the information
to be wrong.
(defmacro bind-if-not-lexical (var &body body &environment env)
(if (eq (variable-kind var env) :lexical) `(progn , . body)
`(let (var) , . body)))
I would expect that the code in the body of the macro
bind-if-not-lexical could depend on var being lexical.
So I could write something like the following:
(defmacro swap (x y &optional (using (gensym)))
`(bind-if-not-lexical ,using
(setq ,using ,x ,x ,y ,y ,using)))
and have the following work correctly:
(defun dumb-test (x y &aux z)
(funny-macro a
(swap x y z)
(swap x y a)))
However, what if funny-macro is defined as follows?
(defmacro funny-macro (var &body body &environment env)
(setq env (augment-environment :variable (list var)))
`(progn , .(mapcar #'(lambda (f) (macroexpand f env))
body)))
We are going to end up referring to the unbound variable a.
This is to be contrasted with the following
(defmacro funny-macro2 (var &body body &environment env)
(setq env (augment-environment :variable (list var)))
`(let (,var) , .(mapcar #'(lambda (f) (macroexpand f env))
body)))
Which is of course all right. At the very least it must be said very
carefully that you cannot go using augment-environment to say things
unless they are true. With variables this is an odd thing to say
because anything that is true about a variable for some external
reason will already be entered into the environment and therefore
there would be no reason to bother to say anything. The only case
where it would ever make sense to use augment-environment is ones like
the one above. And you can always do something like the following instead.
(defmacro funny-macro3 (var &body body)
`(let (,var) , . body))
or if things are really complex
(defmacro funny-macro4 (var &body body)
`(let (,var) (funny-macro4* ',arbitrary-state-info , . body)))
(defmacro funny-macro4* (state-info &body body &environment env)
<arbitrary-processing>)
(The point here being that you have to save some info for when you get
control back after the real macro-processer gets the environment set
up right.)
Note that this problem does not come up in the :symbol-macro and
:macro case because all of the activity is purely confined to the
macro expansion phase of things and therefore in a very real sense
something you say to augment-environment is true simply because you
say it is true.
With declarations things still at least make sense in that you might
have figured somthing out that is true, but is not yet in the
environment.
-----
In summary, it just seems to me that AUGMENT-ENVIRONMENT is not at all
the same kind of thing as the accessors. I can use the accessors any
way I like and things are fine, but I have to be very careful with
AUGMENT-ENVIRONMENT.
If the intention is just to expose a subprimitive that can be used to
support code walkers, then at a minimum I suggest that this be
said loud and clear and that the inputs for :variable and :function be
made syntactically identical to Let/prog/do etc. and flet/labels
binding lists so that code walking will be easy to do. (You did this
with the other three keywords.)
Better yet I suggest getting to the heart of the matter with a form
called something like
WALK-INTO ENV FORM FN
FORM must be one of the key forms that alters the environment
(i.e, let,let*,flet,macrolet,prog, etc.). Walk-into augments its
environment argument as FORM dictates including all declarations. It
then calls FN with two arguments, the body of FORM and the augmented
environment. It returns a copy of FORM with the body replaced by
whatever FN returns. Using this, you could rewrite funny-macro4 as follows
(defmacro funny-macro4+ (var &body body &environment env)
(walk-into env `(let (,var) , . body)
#'(lambda (body env) <arbitrary-processing>)))
You can get into trouble with this too by consing up some special code
and contriving not to put it into the final, but at least the
intention is clear. Also it would be a lot easier to use for code walking.
∂22-Mar-89 1351 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
Received: from Sun.COM by SAIL.Stanford.EDU with TCP; 22 Mar 89 13:51:14 PST
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.0)
id AA11206; Wed, 22 Mar 89 13:52:38 PST
Received: from clam.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA18905; Wed, 22 Mar 89 13:48:39 PST
Received: by clam.sun.com (4.0/SMI-4.0)
id AA08918; Wed, 22 Mar 89 13:52:19 PST
Date: Wed, 22 Mar 89 13:52:19 PST
From: cperdue@Sun.COM (Cris Perdue)
Message-Id: <8903222152.AA08918@clam.sun.com>
To: Gray@dsg.csc.ti.com, dick@wheaties.ai.mit.edu
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
Cc: cl-compiler@sail.stanford.edu, cperdue@Sun.COM
As far as I know, the main application of AUGMENT-ENVIRONMENT is
indeeed intended to be for code-walking: cross-reference analysis,
type-analysis, code transformation, etc.. I think the objectives for
AUGMENT-ENVIRONMENT were to support this activity well.
Unfortunately, the simple definition of WALK-INTO you describe
doesn't quite work.
> WALK-INTO ENV FORM FN
>
> FORM must be one of the key forms that alters the environment
> (i.e, let,let*,flet,macrolet,prog, etc.). Walk-into augments its
> environment argument as FORM dictates including all declarations. It
> then calls FN with two arguments, the body of FORM and the augmented
> environment.
What if FORM is (lambda (x &optional (y (list x)) &aux (z (or x t)) ... )?
The scope of X is not just a body. It is some initialization forms
and also a body.
PCL has a code walker. It is a few hundred lines of code. My sense
is that people are trying to design a subprimitive to make such
a code walker portable. The entire code walker spec. might be too much
to freeze into a standard right now.
-Cris
∂22-Mar-89 1354 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
Received: from cs.utah.edu by SAIL.Stanford.EDU with TCP; 22 Mar 89 13:53:12 PST
Received: from defun.utah.edu by cs.utah.edu (5.61/utah-2.1-cs)
id AA06425; Wed, 22 Mar 89 14:36:13 -0700
Received: by defun.utah.edu (5.61/utah-2.0-leaf)
id AA11763; Wed, 22 Mar 89 14:35:54 -0700
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
Message-Id: <8903222135.AA11763@defun.utah.edu>
Date: Wed, 22 Mar 89 14:35:52 MST
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
To: dick@wheaties.ai.mit.edu
Cc: Gray@dsg.csc.ti.com, cl-compiler@sail.stanford.edu, cperdue@sun.com
In-Reply-To: dick@wheaties.ai.mit.edu, Wed, 22 Mar 89 15:19:40 EST
Just to respond to a few of the points you raised in your message:
AUGMENT-ENVIRONMENT is intended to be used by program analysis
programs, not to add things to the environment in macro functions just
for the heck of it. I'd say that any macro expander that tries to add
things to the environment that aren't really there is broken, because
it doesn't "preserve semantics" of the macro call. There are lots of
other ways users can get into trouble with macros that don't have
anything to do with environments, but I don't think the standard is
going to address that problem.
The reason why it's necessary to put some information about variable
and function bindings in the environment, even though the actual
bindings are not fully defined, is so that they will shadow macro
definitions or global definitions of those variables and functions.
For instance, binding a local function named FOO shadows any macro
definition of FOO in an outer contour.
Code walkers have to pick apart forms like LET and LABELS anyway
(because the initial binding forms and local function definitions have
to be walked in the appropriate environment), so there isn't much
motivation for making the corresponding inputs to AUGMENT-ENVIRONMENT
syntactically identical. All you need is a call to (MAPCAR #'CAR ...)
to extract the right information, anyway. Your suggestion for
WALK-INTO won't work for the same reason -- it would have to walk the
parts of the form that establish the initial values for the bindings,
as well as the body. Also, I've experimented in the past with trying
to write a generic code-walker that used hook functions like you
suggest, and found that it didn't work very well. It didn't give
enough control over the right kinds of information.
-Sandra
-------
∂22-Mar-89 1523 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
Received: from ti.com by SAIL.Stanford.EDU with TCP; 22 Mar 89 15:17:31 PST
Received: by ti.com id AA10725; Wed, 22 Mar 89 15:33:46 CST
Received: from Kelvin by tilde id AA20484; Wed, 22 Mar 89 15:29:19 CST
Message-Id: <2815594040-1067729@Kelvin>
Sender: GRAY@Kelvin.csc.ti.com
Date: Wed, 22 Mar 89 15:27:20 CST
From: David N Gray <Gray@DSG.csc.ti.com>
To: "David A. Moon" <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Cc: Sandra J Loosemore <sandra%defun@cs.utah.edu>,
cl-compiler@SAIL.STANFORD.EDU, cperdue@Sun.COM
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
In-Reply-To: Msg of Tue, 21 Mar 89 18:17 EST from David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
> I like this new version of SYNTACTIC-ENVIRONMENT-ACCESS:SMALL,
> except for two minor comments:
>
> The accessors VARIABLE-INFORMATION, FUNCTION-INFORMATION, and
> DECLARATION retrieve information about declarations that are in
> effect in the environment. Since implementations are permitted to
> ignore declarations (except for SPECIAL declarations), these accessors
> are required only to return information about declarations that were
> explicitly added to the environment using AUGMENT-ENVIRONMENT.
>
> I think this is wrong. Certainly if DECLARATION is to be useful
> implementations must not be allowed to discard any of the declarations
> it can return. As someone from an implementation that ignores type
> declarations, I can say that I think all implementations should be
> required to return all declarations from all three of these functions.
> I think implementations should be permitted to ignore declarations
> in the sense of the code generated by the compiler not being affected
> by declarations, but should not be permitted to just throw declarations
> away rather than putting them into the syntactic environment.
I think there is a fundamental question here of what the purpose of the
proposal is -- is it to
(1) Allow users to gain access to certain information in the compiler's
data structures
or
(2) Require the compiler to do some extra bookkeeping for the user.
I have been assuming purpose (1), while you seem to be assuming purpose
(2).
The only declarations that can be discarded are those which don't change
the semantics of the program. Thus, a macro expander might like to know
what the type of a variable is, or what the OPTIMIZE levels are, but
neither is necessary for it to produce correct code. If someone adds a
bunch of type declarations to their source in order to make the compiled
code faster, would they expect that this would make it run slower when
evaluated? I don't like the idea of forcing the evaluator to remember a
lot of information that it has no use for just in case someone might
possibly ask to see it later.
What you want sounds like the way the special variable LOCAL-DECLARATIONS
was used in the Zetalisp compiler -- all declarations were simply pushed
on the list and anyone could access the variable to look up whatever they
were interested in. This has proven to be very inefficient; everything
that our compiler really cares about is now stored some other way. The
only declarations that we push on LOCAL-DECLARATIONS now are those that
are in a list of declarations that need to be treated that way; this was
just in case some users needed that capability, but I have never seen any
program that did use it. I really don't want to standardize something
like LOCAL-DECLARATIONS unless there are real uses for it, not just
hypothetical ones.
∂22-Mar-89 2115 CL-Compiler-mailer issue LOAD-TIME-EVAL, version 11
Received: from moon.src.honeywell.com (ALTURA.HONEYWELL.COM) by SAIL.Stanford.EDU with TCP; 22 Mar 89 21:06:24 PST
Return-Path: <alarson@src.honeywell.com>
Received: from pavo.SRC.Honeywell.COM by moon.src.honeywell.com (5.59/smail2.6.3/06-17-88);
Wed, 22 Mar 89 23:07:26 CST id AA24581 for cl-compiler@SAIL.STANFORD.EDU
Posted-Date: Wed, 22 Mar 89 23:05:30 CST
Received: by pavo.src.honeywell.com (3.2/SMI-3.2)
id AA25731; Wed, 22 Mar 89 23:05:30 CST
Date: Wed, 22 Mar 89 23:05:30 CST
From: alarson@src.honeywell.com (Aaron Larson)
Message-Id: <8903230505.AA25731@pavo.src.honeywell.com>
To: Moon@STONY-BROOK.SCRC.Symbolics.COM
Cc: cl-compiler@SAIL.STANFORD.EDU
In-Reply-To: David A. Moon's message of Mon, 20 Mar 89 15:46 EST <19890320204610.4.MOON@EUPHRATES.SCRC.Symbolics.COM>
Subject: issue LOAD-TIME-EVAL, version 11
Summary: I must be missing something...
Posted-Date: Mon, 20 Mar 89 15:46 EST
Date: Mon, 20 Mar 89 15:46 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Date: Sun, 19 Mar 89 22:18:17 CST
From: alarson@src.honeywell.com (Aaron Larson)
I find myself strongly opposed to **3.
Read Sandra's answer first.
Well, I appear to be out of it. I've been thinking this over for the last
two days, and I still don't get it. My mental model of what
LOAD-TIME-VALUE gives me is syntactic sugar. E.g.
(defun foo () .... (load-time-value XXX) ...)
could be (assuming DEFINING-MACROS-NON-TOP-LEVEL):
(let ((val XXX))
(defun foo () ... val ...))
My understanding of its need is that it can be difficult for macros to
expand into something like the above without a fair amount of cooperation
from the "top level" defining macro.
From Sandra:
(flet ((foo () (load-time-value (bar))))
(declare (inline foo))
(list (foo) (foo)))
I personally don't see what the inlining example has to do with the issue
at all. If I have a function defined like the following:
(let ((val (make-array ...)))
(defun bar () val))
it seems reasable for the compiler to put a constant value in the body of
bar, but if I then declare it to be inline, I don't see how the compiler
can propagate the constant unless it can ensure that the values it
propagates will always be EQ (for example if it is inlined into functions
from different files, the loader has to be smart enough to make the
constants one and the same at load time, or the inlining operation is not
legal). I would think that the fact LOAD-TIME-VALUE is a special form
encompases this sort of analysis for its resultant value in an analagous
manner.
The talk about EQ structures being coallesced I've always considered bogus,
LOAD-TIME-VALUE denotes a way of computing a value, the fact that it is
somehow not evaluated the next time around is a property of where it
appeared in code, not the identity of the cons cell that made it up. For
example, is anyone considering that it would be legal to have only one
load-time-value expressing in the following:
(defun foo (x)
(if x
#1=(load-time-value ....)
#1#))
My take of the **3 proposal is that foo could become a constant function,
that seems wrong to me, hence I believe the following two programs denote
different computations (the first foo being a constant function, the second
one not):
(defun foo (x)
(flet ((bar () (load-time-value XXX))))
(if x (bar) (bar)))
(defun foo (x)
(macrolet ((bar () '(load-time-value XXX))))
(if x (bar) (bar)))
Moon Again:
The problem is that the **2 proposal is not well specified and thus
cannot be implemented, or will require the implementor to make arbitrary
decisions that will probably come out different ways for different
implementations.
Thus I think it's incumbent on anyone who opposes **3 to propose an
alternative, and I think just going back to **2 is not a viable
alternative.
I guess my problem is that I don't see the implementation lattitude
that you do. Undoubtedly this comes from your far greater experience.
Since we will be in DC in a few days, perhaps someone can take a few
minutes (hours?) to explain it to me. I'll even buy the beer.
∂23-Mar-89 1139 CL-Compiler-mailer issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
Received: from life.ai.mit.edu by SAIL.Stanford.EDU with TCP; 23 Mar 89 11:39:28 PST
Received: from wheat-chex.ai.mit.edu by life.ai.mit.edu; Thu, 23 Mar 89 12:39:56 EST
Received: from localhost by wheat-chex.ai.mit.edu; Thu, 23 Mar 89 12:39:54 EST
Date: Thu, 23 Mar 89 12:39:54 EST
From: dick@wheaties.ai.mit.edu
Message-Id: <8903231739.AA13965@wheat-chex.ai.mit.edu>
To: sandra%defun@cs.utah.edu
In-Reply-To: Sandra J Loosemore's message of Wed, 22 Mar 89 14:35:52 MST <8903222135.AA11763@defun.utah.edu>
Cc: Gray@dsg.csc.ti.com, cl-compiler@sail.stanford.edu, cperdue@sun.com
Subject: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 4
Yes I agree I was over simplifying things. Sorry for taking you all
over what I expect is ground you have all been over before. I also
certainly think that some kind of support facilitating code walking is
better than none.
So all and all, I guess I really only have one suggestion, and that is that
the description of AUGMENT-ENVIRONMENT should be clearer on what it
for. Saying that it is for "constructing enviroments" lead me down the
wrong path all together. Things would have been much clearer to me as
an outside observer if the documentation had made it clear that
facilitating code walking was all it was for.
∂23-Mar-89 2107 CL-Compiler-mailer Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 23 Mar 89 21:07:20 PST
Received: from EUPHRATES.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via INTERNET with SMTP id 563823; 23 Mar 89 15:14:15 EST
Date: Thu, 23 Mar 89 15:13 EST
From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Re: issue SYNTACTIC-ENVIRONMENT-ACCESS, version 5
To: David N Gray <Gray@DSG.csc.ti.com>
cc: Sandra J Loosemore <sandra%defun@CS.UTAH.EDU>, cl-compiler@SAIL.STANFORD.EDU,
cperdue@Sun.COM, Moon@STONY-BROOK.SCRC.Symbolics.COM
In-Reply-To: <2815594040-1067729@Kelvin>
Message-ID: <19890323201357.0.MOON@EUPHRATES.SCRC.Symbolics.COM>
Date: Wed, 22 Mar 89 15:27:20 CST
From: David N Gray <Gray@DSG.csc.ti.com>
I think there is a fundamental question here of what the purpose of the
proposal is -- is it to
(1) Allow users to gain access to certain information in the compiler's
data structures
or
(2) Require the compiler to do some extra bookkeeping for the user.
I have been assuming purpose (1), while you seem to be assuming purpose
(2).
You're right. Not only the compiler, also the interpreter would have to do
the extra bookkeeping. I didn't regard recording those declarations (as
opposed to acting on them) to be a significant effort, but I might be wrong.
The only declarations that can be discarded are those which don't change
the semantics of the program. Thus, a macro expander might like to know
what the type of a variable is, or what the OPTIMIZE levels are, but
neither is necessary for it to produce correct code.
This is no longer true. With the introduction of the concept of "safe code",
it's necessary to know the OPTIMIZE SAFETY level in anything that does not
unconditionally produce safe code.
If someone adds a
bunch of type declarations to their source in order to make the compiled
code faster, would they expect that this would make it run slower when
evaluated?
I would, just because the code is larger.
I don't like the idea of forcing the evaluator to remember a
lot of information that it has no use for just in case someone might
possibly ask to see it later.
I do see your point though.
What you want sounds like the way the special variable LOCAL-DECLARATIONS
was used in the Zetalisp compiler -- all declarations were simply pushed
on the list and anyone could access the variable to look up whatever they
were interested in. This has proven to be very inefficient; everything
that our compiler really cares about is now stored some other way. The
only declarations that we push on LOCAL-DECLARATIONS now are those that
are in a list of declarations that need to be treated that way; this was
just in case some users needed that capability, but I have never seen any
program that did use it. I really don't want to standardize something
like LOCAL-DECLARATIONS unless there are real uses for it, not just
hypothetical ones.
I didn't think the list returned by DECLARATION-INFORMATION would be actually
consed until you asked for it; the information could be remembered in some
other form. The use of a list here was just to maximize the simplicity
and minimize the functionality of the interface.
Would it be reasonable to say that declarations that pertain to variable
bindings and function definitions are remembered at the discretion of the
implementation, but that other declarations (the kind you get at with
DECLARATION-INFORMATION) must be remembered?
Or are we concluding that we're not really ready to standardize
anything for SYNTACTIC-ENVIRONMENT-ACCESS?
∂24-Mar-89 0824 CL-Compiler-mailer issue DEFINE-OPTIMIZER, version 6
Received: from Think.COM by SAIL.Stanford.EDU with TCP; 24 Mar 89 08:23:55 PST
Return-Path: <barmar@Think.COM>
Received: from OCCAM.THINK.COM by Think.COM; Fri, 24 Mar 89 11:21:42 EST
Date: Fri, 24 Mar 89 11:22 EST
From: Barry Margolin <barmar@Think.COM>
Subject: issue DEFINE-OPTIMIZER, version 6
To: Sandra J Loosemore <sandra%defun@cs.utah.edu>
Cc: cl-compiler@sail.stanford.edu
In-Reply-To: <8903232118.AA12741@defun.utah.edu>
Message-Id: <19890324162247.9.BARMAR@OCCAM.THINK.COM>
Date: Thu, 23 Mar 89 14:18:27 MST
From: sandra%defun@cs.utah.edu (Sandra J Loosemore)
The editor is advised that a non-binding style note such as the
following would also be appropriate:
In general, it is poor style for a programmer to define optimizers for
functions that he does not maintain. This is because the correct
implementation of an optimizer for a function usually depends on an
understanding of the internals of that function. As such, a function
definition and any optimizers should be maintained as a unit so that
they can changes in either can be synchronized as appropriate with the
other.
I think is is a bit strong. All that an optimizer writer should need to
know is the externally-visible behavior of the function being optimized.
It may be useful to know the implementation of the function in order to
determine what optimizations are most necessary, but it's often possible
to do a decent job without such knowledge. For example, an optimizer
for * that performs constant folding and recognizes the special case
where one argument is the constant 0 is pretty safe, no matter how * is
implemented.
Perhaps what is intended is a warning that programmers shouldn't define
optimizers for standard CL functions that the implementation might
extend, where the optimizer only implements the standard behavior, since
this might break any internal, non-portable uses of the function within
the implementation.
If a function that has an optimizer function is declared INLINE,
the optimizer has precedence. If a function that has an optimizer
function is declared NOTINLINE, the application of the optimizer
function by OPTIMIZE-EXPRESSION and OPTIMIZE-EXPRESSION-1 is
inhibited.
I'm not sure if this says what it intends to say. The way I read it,
a user-defined function will only be optimized if it is also declared
INLINE. This is because user-defined functions are NOTINLINE by
default. Or is there a difference between functions explicitly declared
NOTINLINE and those whose INLINEness is allowed to default? If so, then
I suggest we give a name to this so that users can make such cases
explicit. However, this is the first time such a need has come up, and
I don't really care for it.
barmar
∂24-Mar-89 0850 CL-Compiler-mailer Re: issue DEFINE-OPTIMIZER, version 6
Received: from multimax.encore.com by SAIL.Stanford.EDU with TCP; 24 Mar 89 08:49:47 PST
Received: from mist.encore.COM by multimax.encore.com with SMTP (5.61/25-eef)
id AA17549; Fri, 24 Mar 89 11:49:31 -0500
Received: from localhost by mist. (4.0/SMI-4.0)
id AA05035; Fri, 24 Mar 89 11:51:25 EST
Message-Id: <8903241651.AA05035@mist.>
To: Barry Margolin <barmar@Think.COM>
Cc: cl-compiler@sail.stanford.edu
Subject: Re: issue DEFINE-OPTIMIZER, version 6
In-Reply-To: Your message of Fri, 24 Mar 89 11:22:00 -0500.
<19890324162247.9.BARMAR@OCCAM.THINK.COM>
Date: Fri, 24 Mar 89 11:51:22 EST
From: Dan L. Pierson <pierson@mist.encore.com>
Date: Fri, 24 Mar 89 11:22 EST
From: Barry Margolin <barmar@Think.COM>
I think is is a bit strong. All that an optimizer writer should need to
know is the externally-visible behavior of the function being optimized.
It may be useful to know the implementation of the function in order to
determine what optimizations are most necessary, but it's often possible
to do a decent job without such knowledge. For example, an optimizer
for * that performs constant folding and recognizes the special case
where one argument is the constant 0 is pretty safe, no matter how * is
implemented.
Part of the point is if a user defines such an optimizer _and_ the
implementation causes user optimizers to override built-in optimizers,
the user might unknowingly override a built-in optimizer that did all
of the above and in addition converted multiplication by small
constant values to inline shifts and adds. In general, defining an
optimizer for code you didn't right (especially built-in code) is
risking a chance that you have accidentally defined a pesimizer
instead.
Of course, you can and should should always test to see that such
optimizers really improve performance by your favorite metric and
don't break the function being optimized (and repeat such tests with
every new version of the implementation). This is a lot of work, and
IMHO, the repeated testing part of it is all too likely to be
neglected.
We're not saying that you should *never* write an optimizer for code
you don't maintain. We are saying that you should think very
carefully about it and we are giving implementations maximum freedom
by saying that defining optimizers for CLtL forms (really for any
implementation forms) are undefined.
∂24-Mar-89 0943 CL-Compiler-mailer Issue: DEFINE-OPTIMIZER
Received: from STONY-BROOK.SCRC.Symbolics.COM (SCRC-STONY-BROOK.ARPA) by SAIL.Stanford.EDU with TCP; 24 Mar 89 09:43:27 PST
Received: from BOBOLINK.SCRC.Symbolics.COM by STONY-BROOK.SCRC.Symbolics.COM via CHAOS with CHAOS-MAIL id 564664; Fri 24-Mar-89 12:39:57 EST
Date: Fri, 24 Mar 89 12:39 EST
From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
Subject: Issue: DEFINE-OPTIMIZER
To: BARMAR@Think.COM
cc: CL-Compiler@SAIL.Stanford.EDU, sandra%defun@cs.utah.edu
In-Reply-To: <19890324162247.9.BARMAR@OCCAM.THINK.COM>
Message-ID: <890324123929.4.KMP@BOBOLINK.SCRC.Symbolics.COM>
I don't think the style warning is too strong.
The issue is not what you have to know about the internals of the function
being optimized, but rather what you have to know about the internals
of DEFINE-OPTIMIZER.
The proposal almost didn't make `escape velocity' (to leave cl-compiler
and get seen by x3j13) because of concern on the part of implementors
that people would try to optimize things in the system. This warning is
intended to put those fears to rest.
The issue is that the proposed definition doesn't tell you if the system
also has optimizers for a function and whether if you define your own you
will clobber the system's. This again was an issue that nearly killed
this proposal on the first pass-- some people want their system optimizers
implemented in terms of this; some people want to do it the other way
around. Rather than fight over it, it's better to just compromise on
a conservative definition.
For functions you wrote, you know no one has written optimizers in advance
so you won't be clobbering anyone's, regardless of how DEFINE-OPTIMIZER
is implemented. For anything else, you can't know for sure what the effect
of doing DEFINE-OPTIMIZER will be in all implementations, so it's best
left vague.
Implementations which provide a full set of meta-level operators for
inspecting the set of optimizers on a function would be within their rights
to (by virtue of that complete set) say you could do an optimizer on
functions you didn't write without feeling guilty. But even then I don't
think everyone would agree that it's still conceptually the right thing.
Anyway, my feeling is that if you pursue your gripe, you'll risk crushing
this fragile proposal and the community as a whole will lose because they
won't be able to write optimizers on -anything- because no operator got
voted in.
-----
I haven't studied the notinline issue enough yet to have an opinion.